Re: [TCLCORE] NULL again, with implementation

[Robert S. <rhs...@gm...>]

Sorry, totally forgot to insert a bit of list formatting... the two points
(with a slight clarification) should have been:

   1. It sounds like you're saying that "the value is undefined", rather
   than "the *value of the* variable is undefined". The difference being
   that a variable can have "no defined value"... but a value, by definition,
   has a value.
   2. By using the reference count, it seems that the ability to test for
   comparison of two values breaks down. Any given empty string will be equal
   to the null value, even if it's not null.


On Thu, May 7, 2009 at 1:00 PM, Robert Seeger <rhs...@gm...> wrote:

> I'm a little confused by your description, as it seems to have a few gaps
> to me:
> It sounds like you're saying that "the value is undefined", rather than
> "the variable is undefined". The difference being that a variable can have
> "no defined value"... but a value, by definition, has a value.
> By using the reference count, it seems that the ability to test for
> comparison of two values breaks down. Any given empty string will be equal
> to the null value, even if it's not null.
>
> The first issue bothers me more than the second, since it's a true semantic
> disagreement with what null means. The second is slightly less of an issue
> since, when you know you can be dealing with nulls you can test for it, and
> when you don't care... you don't care. I would think there would still be
> places where it could bite you, though.
>
> Robert Seeger
>
>
> On Thu, May 7, 2009 at 11:12 AM, Larry McVoy <lm...@bi...> wrote:
>
>> BTW, we implemented NULL in our fork of the tcl tree trivially.  Contrary
>> to all the discussion here, we don't really care if there is a string
>> rep for NULL, we just wanted a way to have an out of band indicator that
>> the value of the variable was undefined or null, whatever you want to call
>> it.
>>
>> I noticed that the ref count for tcl objects is a 32 bit signed quantity,
>> so the most references you could have to an object was 2 billion.  I made
>> it an unsigned 31 bit quantity and used the high bit to mean the object
>> is undefined.  We used an empty string as the object's value but that's
>> neither here nor there, we don't look at it, we added a [defined]
>> proc that just returns the bit.  Tcl can shimmer it all it wants, we
>> don't care.
>>
>> Works great for us and seems to fit into the tcl code reasonably well.
>> I point it out because if you think about it a bit, it's pretty darned
>> unlikely that you need anything like 31 bits for reference counting.
>> I bet that you could use 16 and be fine.  I'm sure Colin will disagree
>> just to disagree, but seems to me that you could steal several bits
>> from the top of the ref count and do the TCL_MEM_DEBUG the same way
>> we did undef instead of making it a negative.
>>
>> ==== generic/tcl.h ====
>> 2009-03-24 05:54:41-07:00, ro...@wo... +10 -1
>>  Add undef field to the Tcl_Obj structure to indicate whether the
>>  object is the L undefined value.
>>
>> --- 1.231/generic/tcl.h 2009-02-13 11:29:39 -08:00
>> +++ 1.232/generic/tcl.h 2009-03-24 05:54:41 -07:00
>> @@ -763,7 +763,16 @@ typedef struct Tcl_ObjType {
>>  */
>>
>>  typedef struct Tcl_Obj {
>> -    int refCount;              /* When 0 the object will be freed. */
>> +#ifndef TCL_MEM_DEBUG
>> +    int refCount:31;           /* When 0 the object will be freed. */
>> +    int undef:1;               /* Used by L to mark an object as having
>> +                                * the undef value.  Steal a bit from
>> +                                * refCount to avoid increasing the
>> +                                * Tcl_Obj memory footprint. */
>> +#else
>> +    int refCount;
>> +    int undef;
>> +#endif
>>     char *bytes;               /* This points to the first byte of the
>>                                 * object's string representation. The
>> array
>>                                 * must be followed by a null byte (i.e.,
>> at
>> --
>> ---
>> Larry McVoy                lm at bitmover.com
>> http://www.bitkeeper.com
>>
>>
>> ------------------------------------------------------------------------------
>> The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
>> production scanning environment may not be a perfect world - but thanks to
>> Kodak, there's a perfect scanner to get the job done! With the NEW KODAK
>> i700
>> Series Scanner you'll get full speed at 300 dpi even with all image
>> processing features enabled. http://p.sf.net/sfu/kodak-com
>> _______________________________________________
>> Tcl-Core mailing list
>> Tcl...@li...
>> https://lists.sourceforge.net/lists/listinfo/tcl-core
>>
>
>