On 9 May 2008, at 13:57, Twylite wrote:
>  Hi,
> > How can $&foo syntax guarantee that a variable named foo exists  
> > any more than upvar can?
>  Upvar can't.  Upvar links to the variable irrespective of whether  
>  it exists or not.  If you try to dereference the local name and the  
>  given variable doesn't exist in the caller's scope then you get an  
>  error.

OK. That's a fair criticism of upvar. It is fixable in Tcl though:

proc myupvar {level varName local} {
     upvar [expr {$level+1}] $varName var
     if {![info exists var]} { return -code error "no such variable  
\"$varName\"" }
     uplevel 1 [list upvar $level $varName $local]
}

proc add10 varName { myupvar 1 $varName var; incr var 10 }
% add10 bar
no such variable "bar"
% set bar 1
1
% add10 bar
11
% set bar
11

Combine this with the wiki code for proc foo {&bar} ... and you seem  
to have all of the advantages of any special syntax.

Note that the existing behaviour of [upvar] does have its uses,  
however -- e.g. it is possible to create constructs that *create*  
variables in the caller's scope with it. That is not possible with $&.

>  [...]
> 
> >> To added advantage to $& over upvar is that the caller can select to
> >> call by reference _or_ by value (discarding potential output from  
> >> the proc).
> >
> > Is that really an interesting thing to do though? It would just  
> > seem to lead to confusion, e.g.:
> >
> >    proc add10 var { incr var 10 }
> >    set foo 1
> >    add10 $foo  ;# does nothing at all - no error
> >
> > With [upvar] you at least get an error in this situation.
> >
>  The example you have given is a function (no side-effects).

That wasn't the intention though -- it is intended to be passed a var  
and mutate it by incrementing it by 10. i.e., the correct code should  
have been:

     add10 $&foo

My point is that the broken code I showed doesn't even give an error  
-- a clear disadvantage in comparison to upvar. It simply does  
nothing. This can only lead to confusion.

>  I have encountered situations when I have had to duplicate a  
>  variable before calling a proc that takes a varname, because I  
>  needed the original value and the return value of the proc, but not  
>  necessarily the changed var value.  I'm struggling to think of a  
>  good example right now but this may suffice:
> 
>  set b alpha -> alpha
>  set c [lappend b beta] -> alpha beta
>  puts $b -> alpha beta
>  puts $c -> alpha beta
> 
>  What if I need "alpha" and "alpha beta", i.e. the original $b and  
>  the final $c?

Then use [linsert] instead of [lappend]:

set c [linsert $b end beta] ->  alpha beta
puts $b ->  alpha
puts $c ->  alpha beta

> 
>  But if lappend had been written to use references:
>  set b alpha -> alpha
>  set c [lappend $&b beta] -> alpha beta
>  puts $b -> alpha
>  puts $c -> alpha beta

That doesn't follow at all from your description of $&-syntax.  
Indeed, I would expect the result of this to be identical to the  
previous version. What you want here is pass-by-value semantics, so  
introducing a syntax for pass-by-reference is no help at all.

-- Neil

This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.


-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Tcl-Core mailing list
Tcl-Core@[...].net
https://lists.sourceforge.net/lists/listinfo/tcl-core