if false {

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

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

 }