set a {1 2}
set b {3 4}
willset c {list $a $b} => {1 2} {3 4}
set b {30 4}
set c => {1 2} {30 4}
proc willset {varName body} {
set trace [uplevel 1 trace vinfo $varName] ;# have previous?
if {$trace != ""} {uplevel 1 eval trace vdelete $varName $trace}
uplevel 1 [list trace var $varName r "set $varName \[$body\];#"]
uplevel 1 [list set $varName]
}Roy Keene Similar to "willset" above, but with only one round of replacement, here is a procedure that will replace a variable with code later on, but only once
## Lazily evaluate a variable once
proc lazyEvalOnce {varName commandPrefix} {
set trace [uplevel 1 trace info variable $varName]
if {$trace ne ""} {
uplevel 1 [list trace remove variable $varName $trace]
}
set isArray false
if {[uplevel 1 [list array exists $varName]]} {
set isArray true
}
set code [list apply {{isArray code name1 name2 args} {
if {$name2 ne "" || $isArray} {
set varname "$name1\($name2\)"
} else {
set varname $name1
}
if {$isArray} {
if {[uplevel 1 [list info exists $varname]]} {
return
}
} else {
uplevel 1 [list unset -nocomplain $varname]
}
append code " " [list $name1 $name2 {*}$args]
set result [uplevel 1 $code]
uplevel 1 [list set $varname $result]
}} $isArray $commandPrefix]
if {$isArray} {
uplevel 1 [list unset -nocomplain $varName]
uplevel 1 [list array set $varName [list]]
} else {
uplevel 1 [list set $varName ""]
}
uplevel 1 [list trace add variable $varName read $code]
return
}Usage: lazyEvalOnce test {apply {args { puts "Fetching remote data"; package require http; set token [http::geturl http://google.com/
]; set retval [http::ncode $token]; http::cleanup $token; return $retval }}}As shown above, deferred assignment with willset easily passes the test given by davidw in linked lists. His added requirement for garbage collection does not seem to be an issue - the trace to an willset variable is automatically deleted when the variable ceases to exist.As shown by Arjen Markus before, linked lists and whatever references may be good for can be implemented in Tcl. It's just that Tcl references are not "physical" pointers, but (as usual) strings: variable names, which are mapped to physical pointers in an internal hash table. The problem of "dangling references" (stored references to objects that do no more exist) is likewise there, but if it occurs, it is rather clearly reported and does not lead to a segmentation fault:
% set a [list 1 2]
% set b [list 3 4]
% willset c {list $a $b}
{1 2} {3 4}
% set b [list 30 4]
30 4
% set c
{1 2} {30 4}
% unset a
% set c
can't read "c": can't read "a": no such variableIntrospection was not explicitly coded: find out what body is tied to a variable withtrace vinfo cMixing eager assignment (with set) and lazy assignment (with willset) currently has the troublesome property that the set returns the new value, but later accesses still fire the trace:
% set c hello => hello
% set c 0> {1 2} {30 4}Obviously, this isn't a finished solution yet... the following write trace didn't work out: #set writetrace "trace vdelete $varName \[trace vinfo $varName\];#"
#uplevel 1 trace var $varName w $writetraceMaybe raising an error is enough for the write trace. Come to think, willset suddenly resembles dynavar from Braintwisters: willset now {clock format [clock seconds] -format %H:%M:%S}
0 % set now
19:37:12
0 % set now
19:37:14Salvatore Sanfilippo - Deferred evaluation, and the above example on lists, for what I can see can't allow you to walk the 'c' list, modify the (say) second element, and see the changes in 'a'. This is a pretty obvious task you can do with real references. Maybe you can manage to have this form of deferred evaluation to work with my counter-example, but it will be easy to find some case when you can't do with it what you can do with references, just because they are a different stuff. Note that I didn't tried it myself, but it seems pretty evident from the code, sorry if I just misreaded your code.Apart from this, references aren't about variables of course, they are about data that reference some other piece of data... so with deferred evaluation you can't build a simple data structure like a tree and walk inside it, modify values, and so on with the 'classical' complexity you found in every CS book. This is enough to make deferred evaluation non-equivalent (but of course an interesting piece of code that shows some kind of lazy-evaluation).
RS Yes. Even if evaluation is deferred into the future, it still follows the Tcl rule of substitution - you can read a value with $value, but if you modify it, a copy will be made, and the original value is unchanged - read-only references, "copy-on-write", somehow like (yet very different from) *const in C. For mutable variables, use the upvar mechanism and call-by-name. But I have yet to be convinced that mutation on values has advantages…
RS Yes. Even if evaluation is deferred into the future, it still follows the Tcl rule of substitution - you can read a value with $value, but if you modify it, a copy will be made, and the original value is unchanged - read-only references, "copy-on-write", somehow like (yet very different from) *const in C. For mutable variables, use the upvar mechanism and call-by-name. But I have yet to be convinced that mutation on values has advantages…
Various other probes into deferred evaluation:
