NULL in Tcl
Chang Li
I do not know if someone has posted this problem.
I think it is useful to have a NULL value in the Tcl.
For example, in the following Tk button command
button .foo -text Name
If the Name is NULL what is happen?
I can not see Name can be NULL as a string. But in
C/C++ it is completely possible to have a NULL string.
If we can set Name to be a NULL then a NULL string or
value can be meaningful. It can be defined if Name
is the NULL then the -text has the default value.
That is a useful way to deal with the dynamic string
value of Name. Tk deals with the default value by
omitting the -text item but I can not see a way to
set it dynamically.
NULL may be a black hole but it is really meaningful.
That value may be convenient to Tcl programming.
Best Regards,
Chang
Jeffrey Hobbs
cha...@silver.cs.umanitoba.ca (Chang Li) writes:
> I think it is useful to have a NULL value in the Tcl.
Support for NULL values was added in Tcl8, and improved with
8.1. You can now have them practically anywhere. The screen
representation of a NULL is \X00, but the Tcl string commands
will recognise it as just another character.
--
Jeffrey Hobbs "I'm really just a Tcl-bot"
jeff.hobbs at acm.org | Jeffrey.Hobbs at oen.siemens.de
Jean-Claude Wippler
> I think it is useful to have a NULL value in the Tcl.
>
> button .foo -text Name
>
> If the Name is NULL what is happen?
If you mean, can a string contain null bytes (\0x00) - then the answer
is "not really": altough Tcl 8.0 allows them, this is no longer the case
in Tcl 8.1a2 - presumably because it interferes with the new Unicode
support in Tcl 8.1 (though 8.1a2 adds "byte arrays" to convert binary
data to and from a Unicode string, including null bytes).
If on the other hand you mean NULL as in C, or as in SQL: this is not
possible, since Tcl has no pointers, and there is no syntax to make a
distinction between strings and reserved words.
In Tcl - generally speaking - NULL and "NULL" are indistinguishable.
So the command "button .foo -text NULL" will create a button which has
the name consisting of four characters: N, U, L, L.
> NULL may be a black hole but it is really meaningful.
Starting with Tcl 8.0, one could define a special Tcl_Obj* object, and
assign it perhaps to the global variable $NULL - but may cause more
problems than it solves.
> That value may be convenient to Tcl programming.
Could you give an example of where/how you would need such NULL values?
-- Jean-Claude
Chang Li
Jean-Claude Wippler <j...@equi4.com> writes:
Maybe it is not clear in the button example for NULL usage in Tk.
See another example
pack .foo -side default
The default should be top, bottom, left, and right. If I am not
clear what value is the default because I am lazy to search
the man page I could set the default to be NULL or {}.
So the default could be top, bottom, left, right, and NULL.
Someone gave a nice NULL expression that is NULL = {}.
Chang
Cameron Laird
In article <changl.8...@silver.cs.umanitoba.ca>,
>For example, in the following Tk button command
>
> button .foo -text Name
>
>If the Name is NULL what is happen?
>
>C/C++ it is completely possible to have a NULL string.
>If we can set Name to be a NULL then a NULL string or
>value can be meaningful. It can be defined if Name
>is the NULL then the -text has the default value.
>That is a useful way to deal with the dynamic string
>value of Name. Tk deals with the default value by
>omitting the -text item but I can not see a way to
>set it dynamically.
>
.
.
... as opposed to the empty string, with which one
conventionally writes
button .foo -text {}
?
--
Cameron Laird http://starbase.neosoft.com/~claird/home.html
cla...@NeoSoft.com +1 713 996 8546 FAX
Jean-Claude Wippler
> pack .foo -side default
>
> The default should be top, bottom, left, and right. If I am not
> clear what value is the default because I am lazy to search
> the man page I could set the default to be NULL or {}.
> So the default could be top, bottom, left, right, and NULL.
>
> Someone gave a nice NULL expression that is NULL = {}.
Ah, ok. Well, technically speaking, some people - including me :) -
will argue that NULL is not the same as an empty string.
What you're proposing can be accomplished by not setting "-side" at all:
pack .foo
If you have a variable which contains the side or is the empty string,
as you suggest, why not use the following -untested- script:
set var top ;# or left, or right, or bottom, or empty
if {$var!=""} {set var "-side $var"}
eval pack .foo $var
I'm not sure that what some consider a solution to laziness is going to
help others, and not just confuse them instead?
But then again, that's just one of so many personal opinions... :)
-- Jean-Claude
John Ellson
Jean-Claude Wippler wrote:
>
> > Someone gave a nice NULL expression that is NULL = {}.
>
> Ah, ok. Well, technically speaking, some people - including me :) -
> will argue that NULL is not the same as an empty string.
Since there are no pointers in tcl the nearest equivalent to
C's NULL pointers is that the variable doesn't exist at all,
which can be tested with:
if {[info exists var]} {...}
So are you saying that NULL should mean NOT_EXISTS when we
are talking about tcl, or are you saying that NULL should
only refer to the NULL_CHARACTER, which, when used in strings,
e.g. "\0", results in existant non-empty strings?
Personally I don't have a problem with the idea of a NULL_STRING
being an empty string in an existant variable.
From the context I read NULL = NULL_STRING into the question, but perhaps
as tcl practitioners we should get into a habit of clearly differentiating
between NULL_STRING v. NULL_CHARACTER v. NOT_EXISTS (v. NULL_POINTER).
John Ellson
Lucent technologies
Jean-Claude Wippler
John Ellson wrote:
> Since there are no pointers in tcl the nearest equivalent to
> C's NULL pointers is that the variable doesn't exist at all,
> which can be tested with:
> if {[info exists var]} {...}
>
> So are you saying that NULL should mean NOT_EXISTS when we
> are talking about tcl, or are you saying that NULL should
> only refer to the NULL_CHARACTER, which, when used in strings,
> e.g. "\0", results in existant non-empty strings?
>
> Personally I don't have a problem with the idea of a NULL_STRING
> being an empty string in an existant variable.
And neither have I - in the context of Tcl, that is... :)
I just wanted to distinguish the different interpretations in order to
find out what the original poster meant (the empty string, apparently).
There's NULL as in C's "#define NULL ((void*) 0)" ...
There's NULL as used very formally in SQL ...
There's NULL as indicated by a zero-length string...
There's NULL as in "\0x00" null bytes ...
And you just added a fifth interpretation - in the context of vars - of
treating unset Tcl variables as null, i.e. "non-existent" ...
> [...] we should get into a habit of clearly differentiating between
> NULL_STRING v. NULL_CHARACTER v. NOT_EXISTS (v. NULL_POINTER).
I agree. My apologies if added to the confusion, 't was not intended.
-- Jean-Claude
Chang Li
John Ellson <ell...@hotair.hobl.lucent.com> writes:
>Jean-Claude Wippler wrote:
>>
>> > Someone gave a nice NULL expression that is NULL = {}.
>>
>> Ah, ok. Well, technically speaking, some people - including me :) -
>> will argue that NULL is not the same as an empty string.
I agree. We can ignore the expression of the NULL now.
>Since there are no pointers in tcl the nearest equivalent to
>C's NULL pointers is that the variable doesn't exist at all,
>which can be tested with:
> if {[info exists var]} {...}
That is a point. In C we know any pointer can be the value NULL.
So the NULL is a common value for any pointer type. We could
use this value conveniently. Why no NULL in Tcl? We can set this
NULL on a string, a list, and other types. It is a common value
for all the Tcl types. I gave a more example why this is helpful.
proc NullTest {idSide idText} {
button .foo -text $idText
pack .foo -side $idSide
}
# a1
NullTest top "Test"
# a2 suppose Tcl has NULL
NullTest NULL "Test"
#a3
NullTest $var "Test"
I hope a1 and a2 should have the same result.
In a1 I have to know top is the default of the -side.
In a2 by using the NULL I suppose pack command know the
-side has the default value. So we may change the
default value of -side to left and the a2 command
is kept from changing.
In a3 if var is not exist (NOT_EXISTS) I think it is
the case of NULL the a3 may still work. We save to
test the variable.
When we define NULL as "\0" and NOT_EXISTS as "\0" we
get a unify expression of a2 and a3.
>So are you saying that NULL should mean NOT_EXISTS when we
>are talking about tcl, or are you saying that NULL should
>only refer to the NULL_CHARACTER, which, when used in strings,
>e.g. "\0", results in existant non-empty strings?
In almost all the case the NULL is defined as 0 in C.
But it may be any value in theory. So we may define
NULL = "\0" in Tcl.
>Personally I don't have a problem with the idea of a NULL_STRING
>being an empty string in an existant variable.
>From the context I read NULL = NULL_STRING into the question, but perhaps
>as tcl practitioners we should get into a habit of clearly differentiating
>between NULL_STRING v. NULL_CHARACTER v. NOT_EXISTS (v. NULL_POINTER).
Yes this is easy to make confusion. It is same as NULL is 0 or not in C.
Chang
>John Ellson
>Lucent technologies
Bruce Stephens
cha...@silver.cs.umanitoba.ca (Chang Li) writes:
> In almost all the case the NULL is defined as 0 in C. But it may be
> any value in theory.
Literal zero integers can be implicitly converted to a null pointer,
in C. I think that's about it, though, although perhaps null pointers
can be converted back again. It's true that lots of programs assume
much more, but they are in error.
> So we may define NULL = "\0" in Tcl.
Why *that*? That's a string of length 1 containing a NUL. Why is
that a suitable value for NULL?
What's wrong with the zero-length string, when you really need a null?
Given that Tcl has happily survived without a NULL, and C manages with
one which only covers pointers (there's no null int in C), and at
least some people think that SQL's NULLs are a bit iffy, what's the
benefit in trying to stick the concept into Tcl?
(Tcl also allows variable names of zero length: "set {} foo" is
legal.)
Chang Li
Bruce Stephens <br...@cenderis.demon.co.uk> writes:
>cha...@silver.cs.umanitoba.ca (Chang Li) writes:
>> In almost all the case the NULL is defined as 0 in C. But it may be
>> any value in theory.
>Literal zero integers can be implicitly converted to a null pointer,
>in C. I think that's about it, though, although perhaps null pointers
>can be converted back again. It's true that lots of programs assume
>much more, but they are in error.
>> So we may define NULL = "\0" in Tcl.
>Why *that*? That's a string of length 1 containing a NUL. Why is
>that a suitable value for NULL?
I agree to you that zero length string is more suitable to be the NULL.
>What's wrong with the zero-length string, when you really need a null?
>Given that Tcl has happily survived without a NULL, and C manages with
>one which only covers pointers (there's no null int in C), and at
>least some people think that SQL's NULLs are a bit iffy, what's the
>benefit in trying to stick the concept into Tcl?
>(Tcl also allows variable names of zero length: "set {} foo" is
>legal.)
Many people object to include the NULL in TCL.
I just want to say you can not ignore the existance of NULL.
The problem is that how can we deal with it.
Chang
Peter.DeRijk
Bruce Stephens (br...@cenderis.demon.co.uk) wrote:
: cha...@silver.cs.umanitoba.ca (Chang Li) writes:
: > In almost all the case the NULL is defined as 0 in C. But it may be
: > any value in theory.
: Literal zero integers can be implicitly converted to a null pointer,
: in C. I think that's about it, though, although perhaps null pointers
: can be converted back again. It's true that lots of programs assume
: much more, but they are in error.
: > So we may define NULL = "\0" in Tcl.
: Why *that*? That's a string of length 1 containing a NUL. Why is
: that a suitable value for NULL?
Indeed it isn't
: What's wrong with the zero-length string, when you really need a null?
What's wrong with it is that an empty string is a legal value: eg:
you might have a widget that displays some text given by a -text option:
someWidget configure -text "This is a text"
The empty string is ofcourse a legal value for this option:
someWidget configure -text ""
will display an empty text for this widget; Now suppose this widget has a
default text to display (that you do not know, or that might even be
dependend on circumstances or other options), it would be nice to say
someWidget configure -text $NULL
to get the widget to display this default text again; notice that this
definately different from an empty string.
: Given that Tcl has happily survived without a NULL, and C manages with
: one which only covers pointers (there's no null int in C), and at
: least some people think that SQL's NULLs are a bit iffy, what's the
: benefit in trying to stick the concept into Tcl?
Another example would be a database interface, where you get a list of
values attributed to some fields. Fields that are not defined could return
a NULL value; again very different from the empty string, that might very
well be a legal value for the field.
"\0" also doesn't cut it as a NULL value, as it might also be a legal
value for something (although less likely).
I think an implementation of NULL in Tcl might be possible in >Tcl8.0,
maybe using a NULL object, or something like that; but I am not a taker
to implement it (It would have to go in the core anyway.)
--
Peter De Rijk der...@uia.ua.ac.be
<a href="http://rrna.uia.ac.be/~peter/personal/peter.html">Peter</a>
To achieve the impossible, one must think the absurd.
to look where everyone else has looked, but to see what no one else has seen.