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

[Neil M. <ne...@Cs...>]

On 18 Jan 2008, at 19:26, Andreas Leitgeb wrote:
> 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.

Yes, indeed. If the goal is to introduce mutable reference cells as a  
first-class object then I think it is better to attempt just that  
rather than to allow Tcl_Objs in general to be mutable. There have  
been some proposals for this in the past, for instance the garbage- 
collected references in Jim. Indeed, the approach Salvatore took  
there looks like a good one to me: take the existing approach of  
using uniquely-named global variables, and then find a way to  
efficiently garbage-collect them (I'm not sure if Jim refs are  
actually variables, but they could be). The non-GC'ed version is as  
simple as:

namespace eval ::ref { variable id 0 }
proc ref val {
     set r ::ref::[incr ref::id]
     set $r $val
     return $r
}
proc ! r { set $r }

# Use
set a [ref 12]
incr $a
puts "a = [! $a]"
trace add variable $a unset [lambda args { puts "BOOM!" }]
unset $a
dict set some deep nested structure [ref 12]
incr [dict get $some deep nested structure]

You seem to get an awful lot for free with this approach.

[ snip stuff I agree with ]

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

Yes, my contention is that by combining values and variables you  
actually end up with the worst of both worlds...

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