On 9 May 2008, at 12:10, Twylite wrote:
>  Hi,
> 
>  This seems to be one heck of a confusing and verbose discussion ;/

Yes, but it makes a nice diversion from endless OO debates.

> > OK, just to be clear: a variable (Var structure in terms of
> > implementation) holds a "strong" reference to a value (Tcl_Obj). That
> > variable is then named in one (or more) contexts/namespaces at the
> > script level -- i.e., there may exist several "weak" references to
> > the variable. Thus there are two levels of reference here: the Var-
> >> Tcl_Obj level and the Name (string)->Var level.
> >
>  Usually a "strong reference" is understood to mean a direct  
>  reference to
>  something that exists, while a "weak reference" is an indirect  
>  reference
>  to something that may or may not exist.
> 
>  For example in C a pointer is a weak reference (the address may be out
>  of range, or the memory cannot be interpreted as the expected type)
>  while a reference is a strong reference.

Well, C++ references aren't that strong (e.g. you can have dangling  
references). SML references are much nicer.

>  In Java a reference is a strong reference, and you can get weak
>  references using (strangely enough) WeakReference.

Which are slightly different again.

> > I need some clarification about what $& notation introduces exactly.
> >
>  I believe Fr?d?ric is suggesting that it is equivalent to an implicit
>  upvar on the name (in the scope of the called proc), but guarantees  
>  that
>  the variable exists.  Using upvar currently provides no such guarantee
>  because the variable name is a weak reference.

How can $&foo syntax guarantee that a variable named foo exists any  
more than upvar can?

> >      proc foo v { ... }
> >      foo $&bar
> >
> > is roughly equivalent to:
> >
> >      proc foo vName { upvar 1 $vName v; ... }
> >      foo bar
> >
> > Is that correct?
> >
>  I believe that is correct if and only if the variable bar exists in  
>  the
>  caller's scope.
> 
>  Consider:
>  proc foo {var} { upvar 1 $var myvar ; puts $myvar }
>  set a 10
>  foo a -> 10
>  foo b -> can't read "myvar": no such variable (while executing "puts
>  $myvar " (procedure "foo" line 1) invoked from within "foo b")
> 
>  But:
>  proc foo {var} { puts $var }
>  set a 10
>  foo $&a -> 10
>  foo $&b -> can't read "b": no such variable (while executing "foo  
>  $&b")

Right -- so the only difference is a slightly improved error message?

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

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