if false {
wdb Inspired by If we had no variables, and some ideas found in Tcl 9.0 WishList, I have some day-dreams of getting rid of set, where the variable is the invoking procedure itself.
instead of saying
% set a apple apple %
we could say
% tcl9var a apple apple %
and instead of saying
% puts "my $a is red" my apple is red %
we could say
% puts "my [a] is red" my apple is red %
and instead of changing the variable a by saying
% set a ${a}tree
appletree
%we could say
% a becomes [a]tree appletree %
Here is a toy implementation of such behaviour:
}
set persistentCounter 0
array set persistent {}
proc tcl9var {name value} {
variable persistentCounter
variable persistent
set persistent([incr persistentCounter]) $value
uplevel 1 [subst {
proc $name {{cmd get} args}\
{eval ::handleVar $persistentCounter \$cmd \$args}
}]
set persistent($persistentCounter)
}
proc handleVar {count cmd args} {
variable persistent
switch -- $cmd {
get {
set persistent($count)
}
set - = - <- - becomes {
eval set persistent($count) $args
}
append - lappend {
eval $cmd persistent($count) $args
}
+ - - - * - / - % - ** -
< - <= - > - >= - == - != {
expr "$persistent($count) $cmd $args"
}
default {
eval $cmd $persistent($count) $args
}
}
}
if false {Possibilities -- see source of proc handleVar above. Variables behave like objects.
Consequences -- closures must handle namespace of procedures instead of variables. Differs from current behaviour where procedures defined globally and procedures defined in current namespace are visible.
Incompatibilities with set -- variables and procedures use the same namespace, so it is not possible to give a var the name of an existing procedure.
Summary -- just a day-dream. (What's wrong with day-dreams? Who said, man will never fly?)
}