tcl-core — Tcl Core Team discussions about Tcl development

Re: [TCLCORE] Tcl(ruby)/Tk Tk::Text

[Mark G. S. <mar...@gm...>]

Jeff Hobbs wrote:
> On 10-May-09, at 7:26 AM, Oleg Puchinin wrote:
>   
>> How to set current position ?
>>     
>
> In Tcl: $text mark set index 1.0
>
> Translate as necessary.
>   

Presumably you mean:

$text mark set insert 1.0

-- 
Mark G. Saye
markgsaye @ gmail.com

Re: [TCLCORE] Tcl(ruby)/Tk Tk::Text

[Jeff H. <je...@ac...>]

On 10-May-09, at 7:26 AM, Oleg Puchinin wrote:
> How to set current position ?

In Tcl: $text mark set index 1.0

Translate as necessary.

[TCLCORE] Tcl(ruby)/Tk Tk::Text

[Oleg P. <gra...@gm...>]

Hi !
How to set current position ?

Oleg.

Re: [TCLCORE] VWAIT documentation

[Donal K. F. <don...@ma...>]

Twylite wrote:
> On this basis I support the proposal to have the above statement (or 
> something similar) included in the man page.

It seems like a reasonable request to me, though I'm not currently sure
what the text should actually look like. However, I think it's possible
to offer additional remedies in 8.6, where you can use a coroutine-based
scheme to write code that *looks* virtually identical to the bad old
[vwait]-based code, but which is in fact event-loop friendly. Thus it
would be good to at least indicate that this is possible in the docs,
making for a substantively different overall flavour...

If someone were to file a bug about this (top-prio) so that it gets
sorted out in time for the next 8.5 and 8.6 releases, that would be a
very good deed.

Donal.

Re: [TCLCORE] NULL again, with implementation

[<lm...@bi...>]

On Fri, May 08, 2009 at 04:51:31PM +0200, Lars Hellstr?m wrote:
> Larry McVoy skrev:
> >On Fri, May 08, 2009 at 12:05:14AM +0200, Lars Hellstr?m wrote:
> >>Larry McVoy skrev:
> >>>It's a fine idea but go look at what the other
> >>>languages do and why
> >>Since you bring it up: Pray tell, *why* do they do what they do? The 
> >>two main reasons AFAICT are:
> >>
> >>1. It's what the other languages do.
> >>2. It's what happens at the level below (i.e., one step closer
> >>   to the silicon).
> >>
> >>Neither is much of a philosophical principle, but perhaps you have 
> >>spotted some deeper meaning underlying the mainstream practices?
> >
> >Try reading this:
> >
> >	http://www.perl.com/pub/a/2007/12/06/soto-11.html
> >
> >and if you get it, great, but if not, I'm really too busy to be dragged
> >into the discussion, I shouldn't have brought the EIAS crap up, my mistake.
> 
> Well, the article is interesting (pages 2-3 anyway; page 1 is just 
> narrative), but it fails to address the issue you brought up, so if 
> there was a pertinent reference you wanted to cite as evidence that Tcl 
> is missing something all other languages has gotten right, then this 
> wasn't it.
> 
> The closest it gets to the issue is the statement (in the page 1 
> dismissal of Tcl) that "The string metaphor tends to have bad 
> performance ramifications," but since the author also claims Tcl lacks 
> a decent extension mechanism ([load], anyone?), it would seem he is 
> talking more about the situation in Tcl7 or earlier than about Tcl8.
> 
> Then again, perhaps the "get it" clause of yours is an elaborate way of 
> saying "Ha ha, only trolling!"?

I already said I shouldn't have brought it up, and that I don't really
have time to argue about it, and that no matter what I say it's like
preaching atheism in church.  The trolling comment is predictable but
doesn't make the point any less (or more) valid, it just encourages
"nah nah, I'm right, you're wrong" and who wants to go there?

I think the fundamental flaw with EIAS is that there are no identities.
That causes all sorts of problems because in tcl

	set foo "hi there"
	set bar "hi there"
	if {$foo eq $bar} { puts "always true" }

but there are lots of cases where you'd like to know if foo is actually 
an alias (upvar, whatever) to bar or if it happens to contain the same
contents as bar.  In tcl, you're pretty much screwed if you care about
that question.  

I suspect that Donal had a few issues with this in the OO layer, haven't
looked.

This is the root of the whole NULL thing, you can't tell if "" is different
from "" so using an empty string for NULL doesn't work.

There are lots of other examples, but I think they all simplify down to 
not being able to do an identity comparison, tcl is limited to a 
content comparison.  

The reason I posted about the undef hack is that it opens up your mind
to using the same idea for other places where you might care about that
sort of information.  Memory debugging for example, which currently is
quite hackish.

That's really all I want to say about this, if you want to come back and
tell me I don't get it, great, then I don't get it.  That's fine and 
we'll leave it at that, or I will at least, I've got too much on my
plate at the moment to preach to an unreceptive audience.
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

Re: [TCLCORE] NULL again, with implementation

[Daniel A. S. <da...@ca...>]

On 08/05/2009, at 16:51, Lars Hellström wrote:

> Then again, perhaps the "get it" clause of yours is an elaborate way  
> of saying "Ha ha, only trolling!"?

now you're indeed "getting it" ;-)

Cheers,

Daniel

-- 
** Daniel A. Steffen                   **
** <mailto:da...@us...>  **

Re: [TCLCORE] NULL again, with implementation

[Lars H. <Lar...@re...>]

Larry McVoy skrev:
> On Fri, May 08, 2009 at 12:05:14AM +0200, Lars Hellstr?m wrote:
>> Larry McVoy skrev:
>>> It's a fine idea but go look at what the other
>>> languages do and why
>> Since you bring it up: Pray tell, *why* do they do what they do? The 
>> two main reasons AFAICT are:
>>
>> 1. It's what the other languages do.
>> 2. It's what happens at the level below (i.e., one step closer
>>    to the silicon).
>>
>> Neither is much of a philosophical principle, but perhaps you have 
>> spotted some deeper meaning underlying the mainstream practices?
> 
> Try reading this:
> 
> 	http://www.perl.com/pub/a/2007/12/06/soto-11.html
> 
> and if you get it, great, but if not, I'm really too busy to be dragged
> into the discussion, I shouldn't have brought the EIAS crap up, my mistake.

Well, the article is interesting (pages 2-3 anyway; page 1 is just 
narrative), but it fails to address the issue you brought up, so if 
there was a pertinent reference you wanted to cite as evidence that Tcl 
is missing something all other languages has gotten right, then this 
wasn't it.

The closest it gets to the issue is the statement (in the page 1 
dismissal of Tcl) that "The string metaphor tends to have bad 
performance ramifications," but since the author also claims Tcl lacks 
a decent extension mechanism ([load], anyone?), it would seem he is 
talking more about the situation in Tcl7 or earlier than about Tcl8.

Then again, perhaps the "get it" clause of yours is an elaborate way of 
saying "Ha ha, only trolling!"?

Lars Hellström

Re: [TCLCORE] NULL again, with implementation

[Donal K. F. <don...@ma...>]

Twylite wrote:
> It DOES NOT extend to lists, which are by definition an ordered set of 
> _values_, and by extension are themselves _values_. 

Actually it does (witness the fact that the concept is well defined on
entries in dictionaries) but Tcl's lists are defined to be not just
ordered but compact - if element 5 exists then elements 0-4 also exist -
and it is only elements from the index [llength $list] onwards (or with
indices less than 0) that do not exist, though [lindex] hides this.

The easiest way of adding a NULL-like thing to Tcl is through explicit
metadata approaches, such as [list 0]/[list 1 $value] or the MAYBE
monad. (The actual "easiest" depends on the details of how you're
implementing; the monad's trivial from C, and [list]-based approaches
are good when pure-scripted. Other techniques are possible too.)

I know Larry doesn't like type theory. Tough luck! This is exactly an
area where type theory is the right tool.

Donal.

Re: [TCLCORE] Finalization vs. Exit

[Donal K. F. <don...@ma...>]

Alexandre Ferrieux wrote:
> Thanks in advance for any insight on this,

Since nobody else has commented, I offer not insight, but rather
encouragement. Finalization is a difficult area (to say the least) and
it merits much study. Part of the difficulty is probably assembling a
good enough set of use cases for all the things that finalization/exit
has to cope with. Indeed, most problems in this area can be traced back
to having an incomplete knowledge of what actually needs to be done.

FWIW, I stay away from finalization; it's one of the areas I don't
tackle at all if I can help it.

Donal.

Re: [TCLCORE] NULL again, with implementation

[Twylite <tw...@cr...>]

Hi,
> Yeah, that's a limitation of living within tcl's retarded philosophy of
> everything is a string.  It's a fine idea but go look at what the other
> languages do and why and you look at the EIAS religion and shake your
> head.  Whatever, I'm not going to change any minds here on that, it's
> like going to church and preaching evolution.
>   
It's got a lot more to do with dynamic versus static languages.

In a static language (or a dynamic language with static semantics like 
variable declaration) the _variable_ exists, and you need to have a way 
to distinguish between "this _variable_ has a _value_" and "this 
_variable_ does NOT have a _value_".

In a dynamic language like Tcl the variable does not have to exist.  So 
you simplify your data model to _variable_ IS _value_, and distinguish 
between "this _variable/value_ exists" and "this _variable/value_ does 
NOT exist".

So in Tcl a function "isnull" or "undefined" would be:
  interp alias {} isnull {} info exists

Tcl is not alone in this approach - Python for example does not have a 
NULL; Everything Is An Object and one of the _values_ that is built into 
Python is an object called "None" that may look & feel a lot like NULL, 
but isn't. 

This DOES extend to Tcl arrays, that is, an associative array or 
unordered collection of _variables_.  If the key doesn't exist you're 
dealing with a NULL, otherwise you're dealing with a non-NULL value.

It DOES NOT extend to lists, which are by definition an ordered set of 
_values_, and by extension are themselves _values_. 

 From previous discussions it sounds like what you want it some sort of 
"vector" data structure that provides indexed access to a "slot" (an 
unnamed variable), such that the "slot" is either empty (NULL) or has a 
value.  This could be done by a vector module or extension without Tcl 
itself having a concept of NULL.  As with arrays, a "vector" would need 
mechanisms for conversion to and from a string representation (if 
desired), because as a collection of _variables_ (as opposed to a 
collection of _values_) it is not itself a _value_.

EIAS is a philosophical underpinning of the Tcl language, just like EIAO 
underpins Python.  Java is "EIAO or NULL, except for basic numeric types 
which are special and may or may not be objects".  Not having to bother 
with types (classes, etc.) and having immutable strings and lists makes 
Tcl extremely powerful, but it comes at a cost: a _variable_ cannot 
exist without a _value_.  If you need to represent such a data model you 
must build the capability on top of Tcl's data model (e.g. the MAYBE 
monad, a "vector" structure, using objects instead of strings, etc).

Regards,
Twylite

Re: [TCLCORE] VWAIT documentation

[<lm...@bi...>]

I'm not a strong voice here but Twylite's request seems pretty reasonable,
just including an example that shows the prob in the docs would be better.
At my company we have a goal: "drive towards zero support costs".  This
request seems in line with that.  If tweaking the docs means less people
ask questions, why not?

On Thu, May 07, 2009 at 09:37:52AM +0200, Twylite wrote:
> Hi,
> >> As such, we will like to request that the following statement
> >> extracted from wiki.tcl.tk/1302 by Chris Nelson to be included in the
> >> standard documentation:
> >>     
> >>    Multiple VWAITS NEST, THEY DO NOT HAPPEN IN PARALLEL. THE
> >> OUTERMOST VWAIT CANNOT COMPLETE UNTIL ALL OTHERS RETURN.
> >>     
> > The standard documentation appears clear on this matter to me.
> > The entire second paragraph of the DESCRIPTION section is
> > devoted to discussing it.
> This has historically been a source of problems for new Tcl users, and I 
> am inclined to feel (now that I have re-read it) that the 8.5 man page 
> for vwait is a little too narrative and does not succinctly explain the 
> behaviour of nested vwaits as the above proposal does. 
> 
> In fact it (the man page) fails completely to explain that unrelated 
> vwaits can cause blocking.  For example:
>   after 500 { vwait b; puts "b was set" }
>   after 1000 { set a 10 }
>   vwait a
>   puts "Never get here"
> 
> This example has nothing to do with "the event handler that sets varName 
> ... not complete[ing] immediately" as described in the man page, but 
> rather that the unrelated "vwait b" creates a new event loop which 
> blocks "vwait a" until the "vwait b" returns.
> 
> On this basis I support the proposal to have the above statement (or 
> something similar) included in the man page.
> 
> Regards,
> Twylite
> 
> 
> ------------------------------------------------------------------------------
> 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

-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

Re: [TCLCORE] NULL again, with implementation

[<lm...@bi...>]

Sorry, Colin, but there have been enough flames that I just don't read
your stuff.  If you really think that I should have someone else forward
it.  And I'm aware this doesn't paint me in the best light but I'm busy
and I just don't have the time to get into it with you.
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

Re: [TCLCORE] NULL again, with implementation (parrot)

[<lm...@bi...>]

Um, while I know Larry, and he even gave me permission to base the L
docs on the perl docs, I'm not that Larry.  He's the more famous
one and he wrote that article, I just pointed to it.

On Thu, May 07, 2009 at 04:23:12PM -0700, Eric P. Melbardis wrote:
> hi
> 
> great article!
> 
> surprised you did not mention partcl (TCL implemented on the Parrot VM)
> 
> 
> eric melbardis
> 
> 
> 
> -----Original Message-----
> From: Larry McVoy [mailto:lm...@bi...] 
> Sent: Thursday, May 07, 2009 3:12 PM
> To: Lars Hellstr?m
> Cc: Tcl Core List; Robert Seeger
> Subject: Re: [TCLCORE] NULL again, with implementation
> 
> On Fri, May 08, 2009 at 12:05:14AM +0200, Lars Hellstr?m wrote:
> > Larry McVoy skrev:
> > >Yeah, that's a limitation of living within tcl's retarded philosophy of
> > >everything is a string. 
> > 
> > C's philosophy that everything is a (fixed width) number seems somewhat 
> > more retarded to me, and most languages escape being retarded about 
> > this only because they don't have a consistent philosophy for values in 
> > the first place...
> > 
> > >It's a fine idea but go look at what the other
> > >languages do and why
> > 
> > Since you bring it up: Pray tell, *why* do they do what they do? The 
> > two main reasons AFAICT are:
> > 
> > 1. It's what the other languages do.
> > 2. It's what happens at the level below (i.e., one step closer
> >    to the silicon).
> > 
> > Neither is much of a philosophical principle, but perhaps you have 
> > spotted some deeper meaning underlying the mainstream practices?
> 
> Try reading this:
> 
> 	http://www.perl.com/pub/a/2007/12/06/soto-11.html
> 
> and if you get it, great, but if not, I'm really too busy to be dragged
> into the discussion, I shouldn't have brought the EIAS crap up, my mistake.
> -- 
> ---
> 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

-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

Re: [TCLCORE] NULL again, with implementation

[Colin M. <co...@ch...>]

Larry McVoy wrote:
> Yeah, that's a limitation of living within tcl's retarded philosophy of
> everything is a string.

Larry, you're on record as saying that you're only interested in ASCII.

I have good news for you:  Tcl represents non-ASCII characters, in which 
you have no interest.  So any application you write can detect a 
non-ASCII character and interpret it as NULL.  There is no need to 
extend the Tcl set of denotatable values, since you can always choose a 
value outside your discursive domain.

Tcl doesn't have a distinguished NULL value (or non-value), just as the 
language of arithmetic doesn't have a value which represents the result 
of evaluating 1/0.  The fact that 1/0 doesn't yield a value in 
arithmetic is not a consequence of religious dogma, but a logical 
consequence of the conventional meaning of '1', '0' and '/'.  To pretend 
that you're a martyr to NULL is as silly as pretending you would be 
burned at the stake for saying 'but it DOES have a value, it's INFINITY 
(and beyond)!' - not persecuted, just silly.

It is certainly the case that the IEEE float and double domains have an 
Inf and a NaN value, but you will see that these values are readily 
distinguishable from the denotations of numerals in their respective 
domains.

I think, given that you only use ASCII, and assuming you can control the 
inputs to your programs, you ought to take a leaf out of IEEE and use 
non-ASCII values to denote your exceptional values, just like the rest 
of us do.

> It's a fine idea but go look at what the other
> languages do and why and you look at the EIAS religion and shake your
> head.  Whatever, I'm not going to change any minds here on that, it's
> like going to church and preaching evolution.
>   

Wouldn't know, don't go to church.

> So you can't do 
>
> 	set foo undef
> 	set bar ""
> 	if {$foo eq $bar} { puts wrong }
>   

But that does work.  "undef" is not equal to "", and so you get 
predictable, useful and consistent behaviour.

> But you can do
>
> 	if {[defined $foo]} { puts wrong }
>
> and that one works fine.  Other than crazy games with undefined unicode
> chars or whatever, you don't have much choice.
>   

If you don't 'believe' in non-ASCII characters, as you have said you 
don't, then I think your applications are safe from heresy, and you can 
use *defined* but non-ASCII unicodes to represent your distinguished 
(non-) value NULL.

Everyone's happy.
Colin.

Re: [TCLCORE] NULL again, with implementation (parrot)

[Eric P. M. <eri...@ne...>]

hi

great article!

surprised you did not mention partcl (TCL implemented on the Parrot VM)


eric melbardis



-----Original Message-----
From: Larry McVoy [mailto:lm...@bi...] 
Sent: Thursday, May 07, 2009 3:12 PM
To: Lars Hellstr?m
Cc: Tcl Core List; Robert Seeger
Subject: Re: [TCLCORE] NULL again, with implementation

On Fri, May 08, 2009 at 12:05:14AM +0200, Lars Hellstr?m wrote:
> Larry McVoy skrev:
> >Yeah, that's a limitation of living within tcl's retarded philosophy of
> >everything is a string. 
> 
> C's philosophy that everything is a (fixed width) number seems somewhat 
> more retarded to me, and most languages escape being retarded about 
> this only because they don't have a consistent philosophy for values in 
> the first place...
> 
> >It's a fine idea but go look at what the other
> >languages do and why
> 
> Since you bring it up: Pray tell, *why* do they do what they do? The 
> two main reasons AFAICT are:
> 
> 1. It's what the other languages do.
> 2. It's what happens at the level below (i.e., one step closer
>    to the silicon).
> 
> Neither is much of a philosophical principle, but perhaps you have 
> spotted some deeper meaning underlying the mainstream practices?

Try reading this:

	http://www.perl.com/pub/a/2007/12/06/soto-11.html

and if you get it, great, but if not, I'm really too busy to be dragged
into the discussion, I shouldn't have brought the EIAS crap up, my mistake.
-- 
---
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

[TCLCORE] Tcl project trackers on SF anti-spam clampdown

[Jeff H. <je...@ac...>]

After seeing that Tix was yet another project to get mass spammed on SF, 
I have gone through and modified _all_ projects that I have admin access 
to on SF and removed anonymous (non-logged in) ticket creation access to 
all trackers.

While I don't want to force anyone to sign up with SF (especially since 
they just recently locked me out from accessing it with FF3 from work 
for some mysterious reason ... though IE8 is ok - yeah?!), this should 
greatly reduce the need to police spam issues.

If you are not one of the following projects, then I highly recommend 
you do the same (Tracker > Admin > foreach tracker > Update Prefs > 
uncheck "Allow non-logged-in postings" > submit).

Modified trackers:

tcl
tktoolkit
tclbitprint
tclsoap
aolserver
incrtcl
tkimg
tcltk
tkcon
tktable
oratcl
sybtcl
isqltcl
tcllib
tclhttpd
tkdnd
tclodbc
expect
tclplugin
tkgs
tclx
tls
tclpro
tktetris
spectcl
tclvfs
tclxpcom
tcldp
tktreectrl
tcltkce

I also removed the remaining spam in the few projects that had been hit.

Jeff

Re: [TCLCORE] NULL again, with implementation

[Lars H. <Lar...@re...>]

Larry McVoy skrev:
> Yeah, that's a limitation of living within tcl's retarded philosophy of
> everything is a string. 

C's philosophy that everything is a (fixed width) number seems somewhat 
more retarded to me, and most languages escape being retarded about 
this only because they don't have a consistent philosophy for values in 
the first place...

> It's a fine idea but go look at what the other
> languages do and why

Since you bring it up: Pray tell, *why* do they do what they do? The 
two main reasons AFAICT are:

1. It's what the other languages do.
2. It's what happens at the level below (i.e., one step closer
    to the silicon).

Neither is much of a philosophical principle, but perhaps you have 
spotted some deeper meaning underlying the mainstream practices?

Skeptically,
Lars Hellström

Re: [TCLCORE] NULL again, with implementation

[<lm...@bi...>]

On Fri, May 08, 2009 at 12:05:14AM +0200, Lars Hellstr?m wrote:
> Larry McVoy skrev:
> >Yeah, that's a limitation of living within tcl's retarded philosophy of
> >everything is a string. 
> 
> C's philosophy that everything is a (fixed width) number seems somewhat 
> more retarded to me, and most languages escape being retarded about 
> this only because they don't have a consistent philosophy for values in 
> the first place...
> 
> >It's a fine idea but go look at what the other
> >languages do and why
> 
> Since you bring it up: Pray tell, *why* do they do what they do? The 
> two main reasons AFAICT are:
> 
> 1. It's what the other languages do.
> 2. It's what happens at the level below (i.e., one step closer
>    to the silicon).
> 
> Neither is much of a philosophical principle, but perhaps you have 
> spotted some deeper meaning underlying the mainstream practices?

Try reading this:

	http://www.perl.com/pub/a/2007/12/06/soto-11.html

and if you get it, great, but if not, I'm really too busy to be dragged
into the discussion, I shouldn't have brought the EIAS crap up, my mistake.
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

Re: [TCLCORE] NULL again, with implementation

[<lm...@bi...>]

On Thu, May 07, 2009 at 01:02:24PM -0400, Robert Seeger wrote:
> 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.

Yeah, that's a limitation of living within tcl's retarded philosophy of
everything is a string.  It's a fine idea but go look at what the other
languages do and why and you look at the EIAS religion and shake your
head.  Whatever, I'm not going to change any minds here on that, it's
like going to church and preaching evolution.

So you can't do 

	set foo undef
	set bar ""
	if {$foo eq $bar} { puts wrong }

But you can do

	if {[defined $foo]} { puts wrong }

and that one works fine.  Other than crazy games with undefined unicode
chars or whatever, you don't have much choice.
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

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

Re: [TCLCORE] NULL again, with implementation

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

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
>

[TCLCORE] NULL again, with implementation

[<lm...@bi...>]

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

Re: [TCLCORE] VWAIT documentation

[Twylite <tw...@cr...>]

Hi,
>> As such, we will like to request that the following statement
>> extracted from wiki.tcl.tk/1302 by Chris Nelson to be included in the
>> standard documentation:
>>     
>>    Multiple VWAITS NEST, THEY DO NOT HAPPEN IN PARALLEL. THE
>> OUTERMOST VWAIT CANNOT COMPLETE UNTIL ALL OTHERS RETURN.
>>     
> The standard documentation appears clear on this matter to me.
> The entire second paragraph of the DESCRIPTION section is
> devoted to discussing it.
This has historically been a source of problems for new Tcl users, and I 
am inclined to feel (now that I have re-read it) that the 8.5 man page 
for vwait is a little too narrative and does not succinctly explain the 
behaviour of nested vwaits as the above proposal does. 

In fact it (the man page) fails completely to explain that unrelated 
vwaits can cause blocking.  For example:
  after 500 { vwait b; puts "b was set" }
  after 1000 { set a 10 }
  vwait a
  puts "Never get here"

This example has nothing to do with "the event handler that sets varName 
... not complete[ing] immediately" as described in the man page, but 
rather that the unrelated "vwait b" creates a new event loop which 
blocks "vwait a" until the "vwait b" returns.

On this basis I support the proposal to have the above statement (or 
something similar) included in the man page.

Regards,
Twylite

Re: [TCLCORE] VWAIT documentation

[<dg...@ni...>]

Abraham Saw <ab...@ma...>:
>  we have recently crashed into an inherent limitations in the VWAIT
> commands which unfortunately was not clearly documented in the
> standard documentation included in releases.

That same documentation is online:

http://www.tcl.tk/man/tcl8.4/TclCmd/vwait.htm
http://www.tcl.tk/man/tcl8.5/TclCmd/vwait.htm

> As such, we will like to request that the following statement
> extracted from wiki.tcl.tk/1302 by Chris Nelson to be included in the
> standard documentation:

>    Multiple VWAITS NEST, THEY DO NOT HAPPEN IN PARALLEL. THE
> OUTERMOST VWAIT CANNOT COMPLETE UNTIL ALL OTHERS RETURN.

The standard documentation appears clear on this matter to me.
The entire second paragraph of the DESCRIPTION section is
devoted to discussing it.

What documentation are you looking at?

DGP

[TCLCORE] VWAIT documentation

[Abraham S. <ab...@ma...>]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
Dear Ladies and Gentlemen,<br>
&nbsp; we have recently crashed into an inherent limitations in the VWAIT
commands which unfortunately was not clearly documented in the standard
documentation included in releases.<br>
<br>
As such, we will like to request that the following statement extracted
from wiki.tcl.tk/1302 by Chris Nelson to be included in the standard
documentation:<br>
<b></b><i><b><br>
&nbsp;&nbsp;&nbsp; Multiple </b></i><b>vwaits </b><i><b>nest, they do not happen in
parallel. The outermost vwait cannot complete until all others return.</b><br>
<br>
</i>Any additional examples deemed useful to highlight this actual
behaviour of VWAIT should be included as well.<br>
<br>
Thank you.<br>
<br>
Yours Truly,<br>
Abraham Saw.<br>
</body>
</html>