Re: [TCLCORE] Empty list is not a list -- using twoPtrValue for NULL type

[Andreas L. <av...@lo...>]

On Fri, Jan 18, 2008 at 04:24:25PM +0000, Neil Madden wrote:
> On 17 Jan 2008, at 23:53, Alexandre Ferrieux wrote:
> > etc. In other words, as seen from the script level, values can just be
> > copied, never passed "by reference".
> 
> Nit picking, but values, strictly speaking, are always immutable.  

That's the point that Alex thinks about to change.

Alex's goal, as far as I understand it, would be "anonymous variables",
or "variables as values".  Think of a "mutable list":
  set mlist [... 1 2 3]
  somefunction $mlist ;#  somefunction incr's the first element of
                       #    it's argument.
  puts $mlist ;# -> "2 2 3"
in principle...

There are of course big lots of problems to be solved, and as of now,
I would rather bet against than for them being ever solved.

> lappend, lset, etc operate on variables, not values. So converting  
> them to also operate on "mutable" values would seem to be quite a  
> large and surprising change in their behaviour.

proc do_something {l} {
   set old_l $l
   lappend l foobar
   puts "old value: $old_l  new value $l"
   return $l
}
ouch, if this gets passed a mutable list.

Alex's response will probaby be like: if you use mutable lists in your
program, then replace the first line by: set old_l [immutable $l]
to get a snapshot in old_l.
But what if the person who wrote that procedure is different from 
the person using it with mutable lists?

> IMO, the correct way to approach any perceived deficit in this area  
> would be to examine why variables are not suitable for the job, and  
> what precisely would need to change to make them suitable.

Variables are not values.  Alex's quest is for some mixture of these,
ideally the best of both worlds.  Values, that can be changed, and that
will be garbage-collected, when no longer used. Like Java-objects.