On 9 May 2008, at 15:42, Twylite wrote:
>  Hi,
> > 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]
> > }
>  Yes, that would be upvar-with-guarantee-that-variable-exists.
> > Combine this with the wiki code for proc foo {&bar} ... and you seem
> > to have all of the advantages of any special syntax.
>  I assume you're talking about Implicit upvar (http://wiki.tcl.tk/ 
>  4535).

Yup.

>  No - you're still missing one thing: with implicit upvar the proc
>  controls the semantics (pass-by-value or pass-by-reference); with $&
>  syntax the caller is in control.

I didn't miss that. I strongly think that the proc should control the  
semantics, as the proc has to implement them.

> > 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  
> > $&.
>  Not even vaguely disputed ;)
> 
> >>>    proc add10 var { incr var 10 }
> >>>    set foo 1
> >>>    add10 $foo  ;# does nothing at all - no error
> > 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  
> > doesnothing. This can only lead to confusion.
>  No more or less confusing that using $d (value) when you meant d
>  (varname), or any other misreading of an API.
> 
>  "add10 $foo" will return 10 and not adjust foo, much like "lappend  
>  $a b
>  c" doesn't complain and doesn't adjust a.

OK, there are commands where this won't raise an error. There are  
others where it does, and it should do (e.g. unset). With the $&  
syntax you are proposing, both calling forms would be valid and it  
would be impossible to catch such errors.

> 
>  Any proc can modify the values of its parameter variable.  Those
>  modifications are lost when the proc returns.  $& syntax provides a  
>  way
>  to keep those values (in the caller's context).  Upvar also allows  
>  a way
>  to keep those values, but the proc must be written to use either a
>  varname (+ upvar) or a value.  $& allows the caller to capture the
>  changes values _if desired_.

The proc must always be written to know whether it is getting a value  
or a variable reference. Otherwise allowing callers to pass in a var  
will result in implementation-specific undefined side-effects being  
performed on the variable. C is not a good model for how a language  
should be designed. Sure you could specifically design a proc to be  
able to handle either, but you could do that now with [upvar] and an  
option (e.g. [foo -var bar] vs [foo $bar]). The caller gets to  
decide, but the callee gets to choose if they even support this mode  
of usage.

> > Then use [linsert] instead of [lappend]:
>  *THWAP*
>  Yes, Tcl offers other ways to accomplish my trivial example.
>  But IF Tcl had $& support, then lappend COULD HAVE been implemented as
>  "lappend listvalue ?value value ...?", allowing you to use it in a  
>  mode
>  with or without side-effects.

*If* [lappend] was implemented in Tcl. It's written in C. As far as I  
am aware, there was nothing in this proposal that $&foo syntax would  
also work with C commands: would they then get passed a Var structure  
rather than a Tcl_Obj? How would that work? It works for procs  
because the parameters are Tcl variables, but in C they aren't, so  
you have to deal with the type mismatch between a value and a  
reference to a value -- either by having separate types of command  
callback, or by making Vars somehow also be Tcl_Objs (i.e. first  
class references, goodbye EIAS).

All that is accomplished is a complication of the syntax and the  
semantics of the language to achieve something which is already  
achievable in a few dozen lines of Tcl code.

-- 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