Hi Gustaf,

On 14 May 2008, at 19:32, Gustaf Neumann wrote:
>  Neil Madden schrieb:
> > What would perhaps be easier to remember would be if variables  
> > were  constant mappings and there was a separate reference type --  
> > then you  could use $foo syntax everywhere. You can do this right  
> > now in Tcl  (modulo garbage collection):
> >
>  Just 2 cents from the xotcl front, concerning variable references.
> 
>  XOTcl provides so-called filters, which are functions called around
>  every invocation of every method of an object. These filters can be
>  registered dynamicaly, they intercept method calls and can call the
>  shadowed methods via "next". This way, one can implement in a few
>  lines e.g. a trace program, which simply intercepts all method calls
>  and prints e.g. the call and exit of the functions.
> 
>  For this situation, relative refernces (the variable one level higher
>  in the callstack) are a problem. If XOTcl would not care about this,
>  programs performing an upvar would be broken, as soon a filter is
>  registered, since the upvar will point to the filter and not to the
>  same method as in the case without the filter. For this reason, XOTcl
>  implements its own upvar (and uplevel) methods to achieve transparency
>  for filters (and mixins as well). This works in general quite well,
>  but people have to write e.g. "my upvar ..."  instead of plain "upvar"
>  to get this transparency.

The ref scheme I outlined above could also work, at the cost of  
storing all state in fully-qualified global/namespace variables.

> 
>  When implementing these methods, i considered as well
>  an alternate approach:
> 
>   - The main problem for this kind of applications
>     are relative upvars (similar holds for uplevels).
> 
>   - Therefore, an option would be to provide an operator
>     (say &) that returns the 'absolute reference'
>     of a variable.
> 
>   - This 'absolute reference' is a symbolic name for the hash table
>     where the variable exists (or should be created) and could either
>     denote a variable on the callstack (say "#12 xxxx") or a
>     namespaced variable (say "::namespace::yyyyy").  This distinction
>     has to be determined by the new operator.
> 
>   - In case, the variable does not exist, one could provide
>     default assumptions (e.g. if called from a proc, it could
>     default to a variable on the callstack).
> 
>   - The dereferencing of the 'absolute reference' could be
>     done either in C for commands like lappend, or it could
>     be done via an addition Tcl command "alias"
> 
>       proc foo {varname} {
>         alias $varname x
>         set x 1
>       }
> 
>       proc bar {} {
>          set y 0
>          foo [& y]
>       }
> 
>  Such absolute references could be easily passed around
>  and are less harmful than the relative upvars, used
>  predominantly in Tcl today.

Something like (arrays left as an exercise):

proc & varName {
   if {$varName in [uplevel 1 [list info locals]]} {
       # Local var
       return [list #[expr {[info level]-1}] $varName]
   } else {
       return [list #0 [uplevel 1 [list namespace which -variable  
$varName]]]
   }
}

proc myincr {ref {amount 1}} {
     upvar {*}$ref var
     incr var $amount
}
proc foo ref { myincr $ref }
proc bar a { foo [& a]; puts "a = $a" }
bar 12 ;# a = 13
set b 10
foo [& b] ;# =>  11

-- 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: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Tcl-Core mailing list
Tcl-Core@[...].net
https://lists.sourceforge.net/lists/listinfo/tcl-core