tcl/tk 9.0 - remove the warts! (?)

4 views
Skip to first unread message

Bryan Oakley

unread,
May 6, 1999, 3:00:00 AM5/6/99
to
Ok, I thought it might be fun to discuss what the tcl communinity
would like to see for tcl 9.0, since tcl 9.0 isn't even on the radar
screen yet. Well, ok, I want to discuss what _I_ want to see for tcl
9.0. Feel free to tell me just how in the weeds I am.

On my bike ride in to work today I was thinking about some of the
warts on tcl (I hate it when I do that!) and thought maybe we should
put forth a plan to remove them. The nutshell idea, then, is to define
a slightly revised tcl language and introduce it as tcl 9.0.

This version would _not_ be backwards-compatible, but
_would_ come with tools to automate the vast majority of the
conversion required for old scripts, or at least identify commands
that have changed (eg: tclsh --compat or something similar)

So, what do I mean by warts? Here's my off-the-top-of-my-head short
list of changes I'd like to see in tcl:

* list command changed to be of the major / minor type:
- list index, list replace, etc instead of lindex, lreplace,
etc.
- the functionality of the existing list command (eg: [list
a b c] would be replaced with [list create a b c]

* treating numbers with leading zeros as octal has got to be
replaced with something that requires an explicit action
(eg: \0o012).

* all commands that do any sort of searching or pattern
matching should have a common set of switches (-nocase,
for example) and a common default.

* all commands that do pattern matching on strings or lists
should have a common set of switches (-glob, -exact, -regexp)
and (maybe) a common default.

* anything that takes a numerical index should accept things
like "end - 1". (ala Jeff Hobbs' extended string command)

* exec should be extended with a -commandline switch, to allow
one to exec a command line with the default shell (eg:
exec -commandline "ls *.foo"). That, or create a new command
called "system" or "run" or something.

* introduce major/minor or something similar, to make it easier
to extend core commands.

* remove the use of tkPriv and use a tk namespace variable
instead.

* get rid of all other pre-defined globals and use a tcl
namespace variable (eg: ::tcl::platform(os))

* maybe (_MAYBE_) add a "pure" comment character, as some
have suggested. I personally don't see much of a need
for one myself, but if the community at large wants it,
this would be the time to do it.

* all core commands would be defined in the tcl or tk
namespace, and the base set would be automatically (or not?)
exported. As new commands are added over time they can
be imported on an as-needed basis to help keep namespace
pollution to a minimum. (this might cause an interesting
catch-22, as how can we define the namespace command in
a namespace?). There might need to be a few exceptions...

this could be used to keep the "kernel" to a minumum (eg:
those commands that are automatically exported) but still
have an expanded "core". Those that need only minimal
tcl functionality could use just the kernel commands and
then pick and choose what other commands to load in.

I'm sure I'll think of others just as soon as I press the send
button. And I haven't thought all these through a whole lot, so I may
change my mind on some of them after a short debate.

The idea here is to remove some of the things that generate
FAQs. Sure, it would be painfull, but most of the changes would be
easy to automate and in the long run make tcl easier to learn. I just
hate seeing some of the same questions over and over again and think
maybe it would be worth it to do something about them.

Part of the process of developing this new version of tcl would be to
define all of the changes up front, then add a switch to tcl 8.x to
flag potential incompatibilities. We could maybe provide pure tcl
libraries that implement many of the changes so people could start
coding to the new method before the final release.

I could probably ramble on for another page or two, but I'll stop now
and ask for comments. I'm curious -- does anyone else think it would
be a good idea to change the language somewhat in the interest of
making it easier to learn and use, at the expense of backward
compatibility?

I'm not absolutely convinced of it myself, but am interested
in debating the issue.

Marco R. Gazzetta

unread,
May 6, 1999, 3:00:00 AM5/6/99
to
Well,

Given the size and quality of your comments, it must have been an awfully long
ride to work! ;}

I felt free to intersperse my impressions in your original posting:

Marco

In article <7gshkd$p...@news2.newsguy.com>,
"Bryan Oakley" <oak...@channelpoint.com> wrote:
[...]


>
> On my bike ride in to work today I was thinking about some of the
> warts on tcl (I hate it when I do that!) and thought maybe we should
> put forth a plan to remove them. The nutshell idea, then, is to define
> a slightly revised tcl language and introduce it as tcl 9.0.
>

[...]


>
> So, what do I mean by warts? Here's my off-the-top-of-my-head short
> list of changes I'd like to see in tcl:
>
> * list command changed to be of the major / minor type:
> - list index, list replace, etc instead of lindex, lreplace,
> etc.
> - the functionality of the existing list command (eg: [list
> a b c] would be replaced with [list create a b c]

Yes! Yes! Yes!


>
> * treating numbers with leading zeros as octal has got to be
> replaced with something that requires an explicit action
> (eg: \0o012).

What, and get rid of that wonderful initiation rite that is you first mail to
the newsgroup with the subject "Why does the interpreter bitch about "08 ==
8"?

>
> * all commands that do any sort of searching or pattern
> matching should have a common set of switches (-nocase,
> for example) and a common default.
>
> * all commands that do pattern matching on strings or lists
> should have a common set of switches (-glob, -exact, -regexp)
> and (maybe) a common default.
>
> * anything that takes a numerical index should accept things
> like "end - 1". (ala Jeff Hobbs' extended string command)

I guess when people say "use C++ for Tcl development", they actually mean:
(a) give me decent support of C++ integration (which would go along with
Pascal, Delphi and (EEEK!) VisualBasic) (b) don't do everything ten million
times slightly differently. I guess if the code was somewhat rationalized
(and those horrible "else if (strncmp(BLABLA,argv[1],length)==0)" removed)
and the interfaces to other languages better defined, then everybody would be
happy with the Tcl core...

>
> * exec should be extended with a -commandline switch, to allow
> one to exec a command line with the default shell (eg:
> exec -commandline "ls *.foo"). That, or create a new command
> called "system" or "run" or something.

Great, remembering all the different command line options of all the different
shells in MS land was a nuisance since tclsh ran the first time.


>
> * introduce major/minor or something similar, to make it easier
> to extend core commands.
>
> * remove the use of tkPriv and use a tk namespace variable
> instead.
>
> * get rid of all other pre-defined globals and use a tcl
> namespace variable (eg: ::tcl::platform(os))

Hmm, that would be VERY low on my list of priorities, I confess


>
> * maybe (_MAYBE_) add a "pure" comment character, as some
> have suggested. I personally don't see much of a need
> for one myself, but if the community at large wants it,
> this would be the time to do it.
>
> * all core commands would be defined in the tcl or tk
> namespace, and the base set would be automatically (or not?)
> exported. As new commands are added over time they can
> be imported on an as-needed basis to help keep namespace
> pollution to a minimum. (this might cause an interesting
> catch-22, as how can we define the namespace command in
> a namespace?). There might need to be a few exceptions...
>
> this could be used to keep the "kernel" to a minumum (eg:
> those commands that are automatically exported) but still
> have an expanded "core". Those that need only minimal
> tcl functionality could use just the kernel commands and
> then pick and choose what other commands to load in.

I fear that keeping the kernel to a minimum includes removing all unnecessary
parts and making them loadable modules. I was thinking of stuff like sockets,
serial I/O, regexp etc., that many people don't use. As far as I know,
Scriptics is trying to make Tk loadable, which would be really great. Let's
go farther on that route!

>
> I'm sure I'll think of others just as soon as I press the send
> button. And I haven't thought all these through a whole lot, so I may
> change my mind on some of them after a short debate.
>
> The idea here is to remove some of the things that generate
> FAQs. Sure, it would be painfull, but most of the changes would be
> easy to automate and in the long run make tcl easier to learn. I just
> hate seeing some of the same questions over and over again and think
> maybe it would be worth it to do something about them.
>
> Part of the process of developing this new version of tcl would be to
> define all of the changes up front, then add a switch to tcl 8.x to
> flag potential incompatibilities. We could maybe provide pure tcl
> libraries that implement many of the changes so people could start
> coding to the new method before the final release.
>
> I could probably ramble on for another page or two, but I'll stop now
> and ask for comments. I'm curious -- does anyone else think it would
> be a good idea to change the language somewhat in the interest of
> making it easier to learn and use, at the expense of backward
> compatibility?

I can't wait for further rambling on your side.


>
> I'm not absolutely convinced of it myself, but am interested
> in debating the issue.
>
>

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own

Don Porter

unread,
May 6, 1999, 3:00:00 AM5/6/99
to
Bryan Oakley <oak...@channelpoint.com> wrote:
> * get rid of all other pre-defined globals and use a tcl
> namespace variable (eg: ::tcl::platform(os))

Better yet, provide command interfaces to all the information
now provided by global variables. (like is now available with
[info library] -> tcl_library and [info patchlevel] -> tcl_patchLevel).

> Sure, it would be painfull, but most of the changes would be

> easy to automate ...

I'm not sure about that. It's easy to globally replace "lsearch"
with "list search" in your scripts, but when Tcl code generates
other Tcl code which is then [eval]'d, I think it's hard to
code a compatibility mode which can figure it all out. Plus
there's tricky cases like:

# I want the first element of my list to be "create"
# Proposed Tcl 9.0 will behave differently
set aList [list create foo bar]

--
| Don Porter, D.Sc. Mathematical and Computational Sciences Division |
| donald...@nist.gov Information Technology Laboratory |
| http://math.nist.gov/mcsd/Staff/DPorter/ NIST |
|______________________________________________________________________|

Bryan Oakley

unread,
May 6, 1999, 3:00:00 AM5/6/99
to
Marco R. Gazzetta <mar...@analogy.com> wrote in message
news:7gspbr$e0v$1...@nnrp1.deja.com...

> Well,
>
> Given the size and quality of your comments, it must have been an awfully
long
> ride to work! ;}

Seven miles, give or take a few hundred yards.

Bryan Oakley

unread,
May 6, 1999, 3:00:00 AM5/6/99
to
Don Porter <d...@clover.cam.nist.gov> wrote in message
news:7gstoh$6dd$1...@clover.cam.nist.gov...

> Bryan Oakley <oak...@channelpoint.com> wrote:
> > * get rid of all other pre-defined globals and use a tcl
> > namespace variable (eg: ::tcl::platform(os))
>
> Better yet, provide command interfaces to all the information
> now provided by global variables. (like is now available with
> [info library] -> tcl_library and [info patchlevel] -> tcl_patchLevel).

A definite possibility


>
> > Sure, it would be painfull, but most of the changes would be
> > easy to automate ...
>
> I'm not sure about that. It's easy to globally replace "lsearch"
> with "list search" in your scripts, but when Tcl code generates
> other Tcl code which is then [eval]'d, I think it's hard to
> code a compatibility mode which can figure it all out. Plus
> there's tricky cases like:
>
> # I want the first element of my list to be "create"
> # Proposed Tcl 9.0 will behave differently
> set aList [list create foo bar]

Oh, agreed. Notice I said "most of the changes...". I am well aware it would
be impossible to find all cases. In that specific case, though, I don't see
a problem. Just replace all occurances of '[list ' with '[list create ' and
you are done. Of course, that would fail on things like "set foo [list
list]; lappend foo create; eval $foo a b c".

I'd wager a piece of scrap paper ;-) most people wouldn't have to spend more
than a day or two to convert all of the code they are responsible for (and
yes, in a past life I've been responsible for several hundren thousands of
lines of tcl code, so I'll stand by that statement).

Of course, I'm also well aware that it may only take a day or two to convert
the code, thoroughly testing the code might take longer, depending on how
extensive your testing code is. I never said it would be pain free or
foolproof.


Ulrich Schöbel

unread,
May 6, 1999, 3:00:00 AM5/6/99
to
Bryan Oakley wrote:
>
> Ok, I thought it might be fun to discuss what the tcl communinity
> would like to see for tcl 9.0, since tcl 9.0 isn't even on the radar
> screen yet. Well, ok, I want to discuss what _I_ want to see for tcl
> 9.0. Feel free to tell me just how in the weeds I am.
>

------------ cut ----------

>
> I'm not absolutely convinced of it myself, but am interested
> in debating the issue.

Hi Bryan,

two items of your list excepted I like your proposals
very much.

I (personally) prefer the old fashioned syntax of
the list commands.

I don't think, that putting most of the core commands
into a namespace is a good idea. If you are afraid of
namespace pollution, use a namespace for your application
(which is a good separation method, anyway).

Additionally, all TclX commands, at least those not covered
by standard Tcl commands, should be included in the core.

Best regards

Ulrich

vcard.vcf

Robert Seeger

unread,
May 6, 1999, 3:00:00 AM5/6/99
to
Bryan,

A well written post. As was noted by Marco, you must has quite a long
ride to work. Anyways, I thought I'd comment on the major/minor idea.
When it comes to list operations, there has been some work done on a
list namespace/package on the Tclers Wiki page. I must admit, I like the
idea of, which is being used there, that there can be a list namespace
with commands like:

list::create
list::append
list::replace

and the like. If this is done, then one could leave the 'list' command
in the global namespace (you can have a command and namespace of the
same name, right?), and that would negate many of the porting problems.
Of course, porting wouls still have to be done, but there would be fewer
gotchas.

Comments?
Rob Seeger

> snip

simon....@royalblue.com

unread,
May 7, 1999, 3:00:00 AM5/7/99
to
Personally, my biggest bugbear with TCL is the positional syntax. Having to
put your braces in particular positions is a real pain and means that I can't
match my layout scheme to that of my C code. Some of the time tcl doesn't
complain it just does something different (switch statement springs to mind).

A read-only 'variable' would be nice - like the C #define.

Jeffrey Hobbs

unread,
May 7, 1999, 3:00:00 AM5/7/99
to Bryan Oakley
Bryan Oakley wrote:
> Ok, I thought it might be fun to discuss what the tcl communinity
> would like to see for tcl 9.0, since tcl 9.0 isn't even on the radar
...

> This version would _not_ be backwards-compatible, but
> _would_ come with tools to automate the vast majority of the

It makes me pause, thinking this. Pause long. I don't know whether
absolute backwards incompatibility is a GOOD THING for the better
good of the language's future, but I guess it depends on how serious
that is, and how good the conversion tools would be.

Do note however that Java made this step in the early days, and
provided an automation tool. At the time, I had stuff that it
didn't convert properly. Fortunately for me, none of it was at
the commercial level, as Java was still very new. In several cases
I just started over from scratch with new docs on the same ideas.

Tcl is very well established. There are millions of lines of Tcl
code out there. The Tcl guys knew this when going from 7 to 8, and
that is why it had very few incompatibilities. As Tcl grows even
further with 8.1 (talk about a great devel platform...), it makes
me pause further to consider that 9.0 should break it all down.
Of course, I see the warts as well...

> * list command changed to be of the major / minor type:
> - list index, list replace, etc instead of lindex, lreplace,
> etc.
> - the functionality of the existing list command (eg: [list
> a b c] would be replaced with [list create a b c]

IF one were to go the namespace and ::list::replace route, then
backwards compatibility is a matter of interp alias. However, then
people might wonder why it's [::list::replace ...] with lists and
[string replace] with strings.

> * treating numbers with leading zeros as octal has got to be
> replaced with something that requires an explicit action
> (eg: \0o012).

Hmmm, the preceding zero for octal isn't just something that comes
out of C, but something that pervades most of the modern languages
now. Note that in the "string is int" command, if you pass it 08
and ask where it failed, it will return the index for the 8.

> * all commands that do pattern matching on strings or lists
> should have a common set of switches (-glob, -exact, -regexp)
> and (maybe) a common default.

I dislike that somehow lsearch got -glob by default, different from
switch, which has the seemingly more logical -exact default.

> * anything that takes a numerical index should accept things
> like "end - 1". (ala Jeff Hobbs' extended string command)

Actually, as I pointed out sometime in that other thread, the change
I made for end-1 in Tcl was in the same function that lists use.
That means lists that supported end before, now support end-1 as well.
I just forgot to document it (a failure on my part that I should fix).

> * exec should be extended with a -commandline switch, to allow
> one to exec a command line with the default shell (eg:
> exec -commandline "ls *.foo"). That, or create a new command
> called "system" or "run" or something.

I would favor a "run" or "system" command, and it is probably best left
to pure Tcl (easiest overall I think).

> * remove the use of tkPriv and use a tk namespace variable
> instead.
>

> * get rid of all other pre-defined globals and use a tcl
> namespace variable (eg: ::tcl::platform(os))

While this would make it nice for Tcl to show itself in good character
with the language features, it seems to be a low priority thing that
would do a lot to break compatibility.

> * maybe (_MAYBE_) add a "pure" comment character, as some
> have suggested. I personally don't see much of a need

I think you mean perhaps a "preprocessed" comment character, or one
that truly avoids brace-balancing in it.

> The idea here is to remove some of the things that generate
> FAQs. Sure, it would be painfull, but most of the changes would be
> easy to automate and in the long run make tcl easier to learn. I just

I wonder though, that even if we had a Tcl with the above changes that
people were already familiar with, would the FAQs be any shorter? I
think they would still be filled with answers to common questions, but
the questions would just have a different nature.

Marco also mentioned the use of:


else if (strncmp(BLABLA,argv[1],length)==0)

all over the core. Actually, this has been cleaned up a lot lately,
and looks much better now in the core (kudos to whoever pioneered that
effort at Scriptics). There are still some places with the above, but
Tcl actually has exported commands to make such cleaner.

** Jeffrey Hobbs jeff.hobbs @SPAM acm.org **
** I'm really just a Tcl-bot My opinions are MY opinions **

Jeffrey.Hobbs.vcf

Bruce S. O. Adams

unread,
May 7, 1999, 3:00:00 AM5/7/99
to

simon....@royalblue.com wrote:

> Personally, my biggest bugbear with TCL is the positional syntax. Having to
> put your braces in particular positions is a real pain and means that I can't
> match my layout scheme to that of my C code. Some of the time tcl doesn't
> complain it just does something different (switch statement springs to mind).
>

This would require a fundermental change to the way the TCL parser works
adding
a lot of (possibly unnecessary) complexity.
I find this ironic myself. I always used the TCL style for my C coding. Then
at
work I was forced into the in line braces scheme which is abhorent to me. Then
TCL came along and reversed the situation. I think it looks better and is more
maintainable to add comments saying exactly what brace was closed anyway:
e.g.
proc foo {} {
puts "hello world"
}
# end proc foo

>
> A read-only 'variable' would be nice - like the C #define.
>

You mean like const in C++ (have they added that to the new C standard?).
You can do lots more ugly and dangerous things with a #define and since
TCL uses #'s as comments you could run it though m4 or whatever preprocessor
you choose anyway. Of course, I would have to shoot you if you did that . . .
:-)
Regards,
Bruce A.


Volker Hetzer

unread,
May 7, 1999, 3:00:00 AM5/7/99
to
Bryan Oakley wrote:
> * list command changed to be of the major / minor type:
> - list index, list replace, etc instead of lindex, lreplace,
> etc.
> - the functionality of the existing list command (eg: [list
> a b c] would be replaced with [list create a b c]
Another question:
Should list create a data structure you can access with "list index $DATA 0"
or should it create a (possibly unnamed) list object you can query
("$DATA index 0")?

Greetings!
Volker

Volker Hetzer

unread,
May 7, 1999, 3:00:00 AM5/7/99
to
Robert Seeger wrote:
>
> Bryan,
>
> A well written post. As was noted by Marco, you must has quite a long
> ride to work. Anyways, I thought I'd comment on the major/minor idea.
> When it comes to list operations, there has been some work done on a
> list namespace/package on the Tclers Wiki page. I must admit, I like the
> idea of, which is being used there, that there can be a list namespace
> with commands like:
>
> list::create
> list::append
> list::replace
>
I don't like this. If a lot of commands would use this, it would lead to
an inflation of namespaces and the danger of conflicts would increase.

Greetings!
Volker

ldup...@cmocbx.qc.bell.ca

unread,
May 7, 1999, 3:00:00 AM5/7/99
to
Don Porter <d...@clover.cam.nist.gov> wrote:
> # I want the first element of my list to be "create"
> # Proposed Tcl 9.0 will behave differently
> set aList [list create foo bar]

Hmmm... to me (and I'm pretty brain-dead this morning) this seems to point to
having the commands in a namespace instead of being major/minor. Ugh, more
typing involved. Yes I know about namespace import but if you start having
"list search" and "string search" and "vector search", namespaces become a
hindrance more than anything else.

Laurent

Bryan Oakley

unread,
May 7, 1999, 3:00:00 AM5/7/99
to
<simon....@royalblue.com> wrote in message
news:7gucj9$qnf$1...@nnrp1.deja.com...

> Personally, my biggest bugbear with TCL is the positional syntax. Having
to
> put your braces in particular positions is a real pain and means that I
can't
> match my layout scheme to that of my C code. Some of the time tcl doesn't
> complain it just does something different (switch statement springs to
mind).

One could argue there is no such thing as a positional syntax in tcl. The
only positional syntax is "command ?arg? ?arg? ?arg? ...". You are free to
put braces whereever you like as long as you don't violate the basic syntax
rules. So, for example, you could do:

proc foo {a b c} \
{
set c [expr $a * $b]
return $c
}

Though I can't think of why you would want to do that.

The trick to remember is, tcl isn't C. It isn't even "C-like". It's not
"like" any other language, and the language elements (notably, curly braces
and double quotes) aren't used like they are in other languages.

In my mind, trying to get tcl to look like C is about as useful as trying to
get C to look like COBOL (though I'm sure someone has accomplished that)

>
> A read-only 'variable' would be nice - like the C #define.

Yeah, I could see a use for that, I suppose. Though I've never personally
been bothered by the lack of that feature.

Peter.DeRijk

unread,
May 7, 1999, 3:00:00 AM5/7/99
to
Robert Seeger (rsee...@nycap.rr.com) wrote:
: Bryan,

: A well written post. As was noted by Marco, you must has quite a long
: ride to work. Anyways, I thought I'd comment on the major/minor idea.
: When it comes to list operations, there has been some work done on a
: list namespace/package on the Tclers Wiki page. I must admit, I like the
: idea of, which is being used there, that there can be a list namespace
: with commands like:

: list::create
: list::append
: list::replace

Actually, I was going that way in my Extral package, but I am not continuing:
Suppose you have a fair share of list commands coded in Tcl (and I try
to always make Tcl-only versions as well as compiled), and suppose
you (or someone else) adds eg. a list::set command, your entire collection
is going to fail. (For the uninitiated: this would mean that every set command
in you list::something procs will suddenly call list::set instead of set).
I am now thinking of converting to
list_pop
list_common
list_union
list_sub
...

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

Volker Hetzer

unread,
May 7, 1999, 3:00:00 AM5/7/99
to
Bryan Oakley wrote:

> One could argue there is no such thing as a positional syntax in tcl. The
> only positional syntax is "command ?arg? ?arg? ?arg? ...". You are free to
> put braces whereever you like as long as you don't violate the basic syntax
> rules. So, for example, you could do:
>
> proc foo {a b c} \
> {
> set c [expr $a * $b]
> return $c
> }

I do that always. Well, I do it:


proc foo {a b c} \
{

#Body goes here.
}

Why?
Because I like it that way.

Greetings!
Volker

Marco R. Gazzetta

unread,
May 7, 1999, 3:00:00 AM5/7/99
to
Hi, Peter!

You are aware of the circumstance that the commands you are creating are at
least partly already in TclX, aren't you?

Marco

In article <37330...@news.uia.ac.be>,

-----------== Posted via Deja News, The Discussion Network ==----------

Paul Duffin

unread,
May 7, 1999, 3:00:00 AM5/7/99
to
Ulrich Schöbel wrote:
>
> Bryan Oakley wrote:
> >
> > Ok, I thought it might be fun to discuss what the tcl communinity
> > would like to see for tcl 9.0, since tcl 9.0 isn't even on the radar
> > screen yet. Well, ok, I want to discuss what _I_ want to see for tcl
> > 9.0. Feel free to tell me just how in the weeds I am.
> >
>
> ------------ cut ----------
>
> >
> > I'm not absolutely convinced of it myself, but am interested
> > in debating the issue.
>
> Hi Bryan,
>
> two items of your list excepted I like your proposals
> very much.
>
> I (personally) prefer the old fashioned syntax of
> the list commands.
>

Simply for compatabilities sake I think it better to have
a list command and subcommands, it makes it easier to see
what type you are trying to play with and would be much
easier to extend.

> I don't think, that putting most of the core commands
> into a namespace is a good idea. If you are afraid of
> namespace pollution, use a namespace for your application
> (which is a good separation method, anyway).
>

The problem I see is when a new command is added to the
core it is placed in the global namespace, I think that
new commands should be added into the ::tcl namespace
because otherwise there is the chance that you will
break existing code.

> Additionally, all TclX commands, at least those not covered
> by standard Tcl commands, should be included in the core.
>

No, no, no, I think that we certainly need to ship more
extensions both binary and Tcl with the core but I do
not think that we should add them into the core library.

--
Paul Duffin
DT/6000 Development Email: pdu...@hursley.ibm.com
IBM UK Laboratories Ltd., Hursley Park nr. Winchester
Internal: 7-246880 International: +44 1962-816880

Marco R. Gazzetta

unread,
May 7, 1999, 3:00:00 AM5/7/99
to
In article <3732EC89...@sni.de>,
But that's exactly what the compiler does!

You send in a string and ask for an index? The string is transformed into a
Tcl_ListObj and keeps running around that way until some evil villain makes
it a string again (or a number, or whatever else comes to your mind).

That's one of the major improvements the compiler brought.

Marco

Paul Duffin

unread,
May 7, 1999, 3:00:00 AM5/7/99
to
Bryan Oakley wrote:
>
> Ok, I thought it might be fun to discuss what the tcl communinity
> would like to see for tcl 9.0, since tcl 9.0 isn't even on the radar
> screen yet. Well, ok, I want to discuss what _I_ want to see for tcl
> 9.0. Feel free to tell me just how in the weeds I am.
>
> On my bike ride in to work today I was thinking about some of the
> warts on tcl (I hate it when I do that!) and thought maybe we should
> put forth a plan to remove them. The nutshell idea, then, is to define
> a slightly revised tcl language and introduce it as tcl 9.0.
>
> This version would _not_ be backwards-compatible, but
> _would_ come with tools to automate the vast majority of the
> conversion required for old scripts, or at least identify commands
> that have changed (eg: tclsh --compat or something similar)
>
> So, what do I mean by warts? Here's my off-the-top-of-my-head short
> list of changes I'd like to see in tcl:
>
> * list command changed to be of the major / minor type:
> - list index, list replace, etc instead of lindex, lreplace,
> etc.
> - the functionality of the existing list command (eg: [list
> a b c] would be replaced with [list create a b c]
>

This should certainly be done although it would break an awful
lot of code, what about calling it something other than list.

> * treating numbers with leading zeros as octal has got to be
> replaced with something that requires an explicit action
> (eg: \0o012).
>

Moving away from the syntax of C could have some benefits but
also some disadvantages.

> * all commands that do any sort of searching or pattern
> matching should have a common set of switches (-nocase,
> for example) and a common default.
>

I love consistency.

> * all commands that do pattern matching on strings or lists
> should have a common set of switches (-glob, -exact, -regexp)
> and (maybe) a common default.
>

And again. The regular expression mechanism should probably be a
loadable module, not everyone uses it.

> * anything that takes a numerical index should accept things
> like "end - 1". (ala Jeff Hobbs' extended string command)
>

If you are going to break compatability why not just say that
negative indexes are relative to the length of the thing.
-1 = end
-2 = end - 1

It would be simpler and quicker than parsing "end-1" although
maybe not quite so readable.

> * exec should be extended with a -commandline switch, to allow
> one to exec a command line with the default shell (eg:
> exec -commandline "ls *.foo"). That, or create a new command
> called "system" or "run" or something.
>

I would go for creating an extension which added system specific
stuff.

> * introduce major/minor or something similar, to make it easier
> to extend core commands.
>

Yes.

> * remove the use of tkPriv and use a tk namespace variable
> instead.
>

Yes.
On the subject of Tk I would like to see those horrible binding
substitutions removed and replaced with an object which I can
query to get the event information.

> * get rid of all other pre-defined globals and use a tcl
> namespace variable (eg: ::tcl::platform(os))
>

Would help to clean things up a bit. Also add things like
whether tcl has been compiled to support threads, stubs etc.

> * maybe (_MAYBE_) add a "pure" comment character, as some
> have suggested. I personally don't see much of a need

> for one myself, but if the community at large wants it,
> this would be the time to do it.
>

I don't think we need one.

> * all core commands would be defined in the tcl or tk
> namespace, and the base set would be automatically (or not?)
> exported. As new commands are added over time they can
> be imported on an as-needed basis to help keep namespace
> pollution to a minimum. (this might cause an interesting
> catch-22, as how can we define the namespace command in
> a namespace?). There might need to be a few exceptions...
>

Maybe incompatability can be reduced by adding the new commands
to the namespace (e.g. list create ...) and then users can
import them.

All the old functions which are to be deprecated should be
placed in a compatabilty extension which is auto loaded.

> this could be used to keep the "kernel" to a minumum (eg:
> those commands that are automatically exported) but still
> have an expanded "core". Those that need only minimal
> tcl functionality could use just the kernel commands and
> then pick and choose what other commands to load in.
>

As for restructuring the internals I have lots of ideas, see
the description of my Feather extension at
http://216.71.55.6/cgi-bin/wikit/402.html
for some waffle on it.

Bryan Oakley

unread,
May 7, 1999, 3:00:00 AM5/7/99
to
Volker Hetzer <hetze...@sni.de> wrote:

> I do that always. Well, I do it:
> proc foo {a b c} \
> {
> #Body goes here.
> }
>
> Why?
> Because I like it that way.

By far the absolute best reason for doing it that way.

Robert Seeger

unread,
May 7, 1999, 3:00:00 AM5/7/99
to
Peter,

I can see your point here, but I don't really agree. I see your
arguement as an arguement against namespaces as a whole. I'd be inclined
to think that, if an individual creates a <namespace>::set command, they
should expect problems like this. If we really want people to be able to
extend the list namespace without worrying about such things, perhaps
the code in the namespace should fully qualify every call to commands in
the global namespace, ie, all set commands should be ::set instead.

Comments,
Rob Seeger

--
Whenever you're having a bad day, and it seems like everyone's
trying to piss you off, remember this - it takes 43 muscles to
frown, but only 4 to pull the trigger of a decent sniper rifle.
- Sorry, I stole this .sig, but I love it. . .

Jeff Gosnell

unread,
May 7, 1999, 3:00:00 AM5/7/99
to
down \/

Paul Duffin wrote in message <373314...@mailserver.hursley.ibm.com>...
>Bryan Oakley wrote:


<snip>

>> * anything that takes a numerical index should accept things
>> like "end - 1". (ala Jeff Hobbs' extended string command)
>>
>
>If you are going to break compatability why not just say that
>negative indexes are relative to the length of the thing.
> -1 = end
> -2 = end - 1
>
>It would be simpler and quicker than parsing "end-1" although
>maybe not quite so readable.
>

imho, If you use {-1 = end} then that would lose some consistency on
what -1 means. Whenever I see -1, I think "Does not exist". i.e. [lsearch
$somelist $something] == -1, $something does not exist in $somelist.
Jeff Gosnell

Duncan Barclay

unread,
May 7, 1999, 3:00:00 AM5/7/99
to
In article <7gshkd$p...@news2.newsguy.com>,

"Bryan Oakley" <oak...@channelpoint.com> writes:
> Ok, I thought it might be fun to discuss what the tcl communinity
> would like to see for tcl 9.0, since tcl 9.0 isn't even on the radar
> screen yet. Well, ok, I want to discuss what _I_ want to see for tcl
> 9.0. Feel free to tell me just how in the weeds I am.

Most/all of comments from others are fine by me.

Given the recent interest and debates on how to get the best from the
compiler is it also time to think of typing data structures in tcl? We
are in a messy situation where it is easy to write code that performs
badly just because what worked equivantly in Tcl < 8.0 actually is
different in Tcl >= 8.0.

My two penn'th is a few changes in Tk:

- extend option get to allow the use of the option database to store
values that can be looked up outside of the Tk core window context (i.e.
allow
set fred [option get *.foo.bar]

- change the coordinate handling on canvas items from strings to
lists so we don't have to do:
canvas .c
set item [.c create item rectangle 100 100 200 200]
...
eval .c coords $item $x $y $x1 $y1
but just pass a list
.c coords $item [list $x $y $x1 $y1]
so it compiles.

- background stipples/pixmaps/bitmaps whatever for widgets (esp.
the canvas)

- get mega widget support properly supported:
- find the mega widget for this component in bindings
- bindings that can be applied to the mega-widget and
propogate down (we be done wit bindtags at present)
- etc. we've done this to death in the past few months so hit
dejanews.

Duncan

--
________________________________________________________________________
Duncan Barclay | God smiles upon the little children,
dm...@ragnet.demon.co.uk | the alcoholics, and the permanently stoned.
________________________________________________________________________

Don Libes

unread,
May 7, 1999, 3:00:00 AM5/7/99
to
"Jeff Gosnell" <jmgo...@athena.louisville.edu> writes:
> Paul Duffin wrote in message <373314...@mailserver.hursley.ibm.com>...
> >Bryan Oakley wrote:
> >> * anything that takes a numerical index should accept things
> >> like "end - 1". (ala Jeff Hobbs' extended string command)
> >
> >If you are going to break compatability why not just say that
> >negative indexes are relative to the length of the thing.
> > -1 = end
> > -2 = end - 1
> >
> >It would be simpler and quicker than parsing "end-1" although
> >maybe not quite so readable.
> >
>
> imho, If you use {-1 = end} then that would lose some consistency on
> what -1 means. Whenever I see -1, I think "Does not exist". i.e. [lsearch
> $somelist $something] == -1, $something does not exist in $somelist.

The solution is make lsearch (and others) return something else, like
{} instead of -1. Returning -1 has always seemed kinda dumb to me.
My code could just as easily check for "BOGUS" as "-1". I've never
found any use for the coincidence that -1 appears to have some
mathematical property.

In any case, I like Jeffrey's suggestion but I like the use of plain
negative integers for reverse indexing even more. But then, this
isn't new. I remember APL (25 years old now?) supported it. Now if
only I could remember how APL indicated "element not found"....

Don

lvi...@cas.org

unread,
May 8, 1999, 3:00:00 AM5/8/99
to

According to Jeffrey Hobbs <Jeffre...@icn.siemens.de>:

:Bryan Oakley wrote:
:> Ok, I thought it might be fun to discuss what the tcl communinity
:> would like to see for tcl 9.0, since tcl 9.0 isn't even on the radar
: ...
:> This version would _not_ be backwards-compatible, but
:> _would_ come with tools to automate the vast majority of the
:
:It makes me pause, thinking this. Pause long. I don't know whether
:absolute backwards incompatibility is a GOOD THING for the better
:good of the language's future, but I guess it depends on how serious
:that is, and how good the conversion tools would be.


What I've suggested in other language forums when major breaks are considered
is that perhaps the better approach would be to give the creation being
discussed a new name. If major changes are made to the language which say
would result in a significant amount of the programs to fail, then one
really has created a new language, based on the original code perhaps,
and perhaps even retaining a significant number of design philosophies.

There's nothing wrong with that - why NOT create a new generation language?
Think of how Unix went from Bourne shell to totally incompatible csh and
minorly incompatible ksh to tcsh, bash and zsh. There are pockets where
each are popular and usable, without displacing the original Bourne
shell...

--
<URL: mailto:lvi...@cas.org> Quote: Saving the world before bedtime.
<*> O- <URL: http://www.purl.org/NET/lvirden/>
Unless explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.

Andreas Kupries

unread,
May 8, 1999, 3:00:00 AM5/8/99
to
Marco R. Gazzetta <mar...@analogy.com> writes:

> Hi, Peter!
>
> You are aware of the circumstance that the commands you are creating are at
> least partly already in TclX, aren't you?

And in many other extensions and packages as well.

See
http://purl.org/thecliff/tcl/wiki/ChartOfExistingListFunctionality

for a chart.

And if anyone is aware or more packages and functions and ... please
either add them directly to the given page, or send them to me, so
that I am able to update that page.

And
http://purl.org/thecliff/tcl/wiki/List

lists all pages on the wiki with regard to list functionality


--
Sincerely,
Andreas Kupries <a.ku...@westend.com>
<http://www.westend.com/~kupries/>
-------------------------------------------------------------------------------

Andreas Kupries

unread,
May 8, 1999, 3:00:00 AM5/8/99
to

Paul Duffin <pdu...@mailserver.hursley.ibm.com> writes:
> Bryan Oakley wrote:
> > * remove the use of tkPriv and use a tk namespace variable
> > instead.

> Yes. On the subject of Tk I would like to see those horrible
> binding substitutions removed and replaced with an object which I
> can query to get the event information.

Implications: Bindings can be changed to be restricted to procedures
(or lambdas, **) with a single argument. As these can be byte-compiled
execution is faster. If the user wants to use a procedure with more
than one argument (s)he has to create a curried command with only the
event argument not defined (**).

(**) All of this obviously plays nice together with Feather :-).


> > * get rid of all other pre-defined globals and use a tcl
> > namespace variable (eg: ::tcl::platform(os))
> >

> Would help to clean things up a bit. Also add things like whether
> tcl has been compiled to support threads, stubs etc.

Extend this to allow questions like 'What OS features do I have' (*)
or 'which patches were applied'.

(*) See 'infox' command in TclX.


> > * maybe (_MAYBE_) add a "pure" comment character, as some
> > have suggested. I personally don't see much of a need
> > for one myself, but if the community at large wants it,
> > this would be the time to do it.

> I don't think we need one.

Seconded.


> As for restructuring the internals I have lots of ideas, see
> the description of my Feather extension at
> http://216.71.55.6/cgi-bin/wikit/402.html

Nitpicking:
The prefered url is
http://purl.org/thecliff/tcl/wiki/402.html

as that will not change over time (purl = persistent url). And

http://purl.org/thecliff/tcl/wiki/Feather

is even better, because of enhanced readability. The
auto-search of the wiki is quite nice here.


> for some waffle on it.

--

Dave LeBlanc

unread,
May 9, 1999, 3:00:00 AM5/9/99
to
On Thu, 6 May 1999 10:56:39 -0600, "Bryan Oakley"
<oak...@channelpoint.com> wrote:

<snip>


> * list command changed to be of the major / minor type:
> - list index, list replace, etc instead of lindex, lreplace,
> etc.
> - the functionality of the existing list command (eg: [list
> a b c] would be replaced with [list create a b c]
>

Dr O, in his book (section 28.3), mentioned that he would have liked
to have been consistent in command forms for Tcl, but it didn't grow
that way (my paraphrase). As I recall, one way he mentioned was a
truely OO sort of Idea which I would expess as:

set myList [List new a b c]
<< myList
myList index a;
<< 0
myList at: 1
<< b
myList replace a d;
<< {d b c}
myList at: 2 put: g
<< {d b g}
(this keyword sort of construct is a bit of a push for tcl since proc
definition might be problematical: proc at:put: {num val} { ...}
whereas it would be neat to see: proc at: {num} put: { val} { .... }
maybe? Hmm.. maybe even List proc at: {num} put: {val} { .... } to add
a new minor to the List class.)
etc.

In like vein:

set myFile [File new]
myFile openOn "foo.txt" mode "+a"

or with a little syndatic sugar:
myFile openOn: "foo.txt" mode: "+a"
(using ":" to indicate that the minor (actually method) "openOn" and
mode: commands take an arguement.)

myFile close
(no need for a ":" here since close does not take an arguement, it's a
directive to the object represented by "myFile".

Anyone who knows the language will see the resemblance to Smalltalk,
but Tcl will still be Tcl if this where done imho.

> * treating numbers with leading zeros as octal has got to be
> replaced with something that requires an explicit action
> (eg: \0o012).
>

Yes please! Let's have decimal the implicit base for all unadorned
numbers.

<snip>

Dave LeBlanc

Peter.DeRijk

unread,
May 10, 1999, 3:00:00 AM5/10/99
to
Robert Seeger (rsee...@nycap.rr.com) wrote:
: Peter,

: I can see your point here, but I don't really agree. I see your
: arguement as an arguement against namespaces as a whole. I'd be inclined
: to think that, if an individual creates a <namespace>::set command, they
: should expect problems like this. If we really want people to be able to
: extend the list namespace without worrying about such things, perhaps
: the code in the namespace should fully qualify every call to commands in
: the global namespace, ie, all set commands should be ::set instead.

I have been trying this using namespaces, and already have been bitten
by the problem I mentioned several times. It is a pain to use ::
for every basic Tcl command (and easy to forget, and it looks ugly too).
Now I am wondering why I would do this using namespaces? Nobody is
going to import this type of functions: there is way to much chance
for overlap with other extensions (string, array, ...). So using
namespaces causes several problems, and it doesn't seem to give any
benefits ...

Peter.DeRijk

unread,
May 10, 1999, 3:00:00 AM5/10/99
to
Andreas Kupries (a.ku...@westend.com) wrote:

: Marco R. Gazzetta <mar...@analogy.com> writes:
:
: > Hi, Peter!
: >
: > You are aware of the circumstance that the commands you are creating are at
: > least partly already in TclX, aren't you?

I am aware of that. But TclX does not contain all the extra list functionality
I need, and it contains a lot of other functionality I don't need. Also
partability is an issue: Extral has a Tcl-only version, which I don't
have for TclX.

: And in many other extensions and packages as well.

: See
: http://purl.org/thecliff/tcl/wiki/ChartOfExistingListFunctionality

: for a chart.

Yes, my Extral extension seems to be rather well represented on this page,
although you seemed to have missed quite some of its functionality.
Anyway, when I get Extral naming cleaned up, functionality should be clearer.

Andreas Kupries

unread,
May 10, 1999, 3:00:00 AM5/10/99
to

der...@uia.ua.ac.be (Peter.DeRijk) writes:

> : And in many other extensions and packages as well.

> : See
> : http://purl.org/thecliff/tcl/wiki/ChartOfExistingListFunctionality

> : for a chart.

> Yes, my Extral extension seems to be rather well represented on this
> page, although you seemed to have missed quite some of its
> functionality.

Hm, list functionality, or other things ?

If possible please add any missing list functionality from Extra-L to
the above page. The more complete, the better.

Jeffrey Hobbs

unread,
May 11, 1999, 3:00:00 AM5/11/99
to Dave LeBlanc
Dave LeBlanc wrote:

> <oak...@channelpoint.com> wrote:
> > * treating numbers with leading zeros as octal has got to be
> > replaced with something that requires an explicit action
> > (eg: \0o012).

> Yes please! Let's have decimal the implicit base for all unadorned
> numbers.

OK, this is something that some seem to want changed, but is *highly*
unlikely to ever see changed, as it involves one of Tcl more deeply
seated roots in C. People wonder why langauges adopt the conventions
of C for integer formats... Well, if you are actually based on C, as
Tcl is, and you don't create your own strtol (string to long) function,
than you inherit C's interpretation of integers.

That is the case with Tcl. At its heart (in many places), it uses
strtol as the "integer identifier". strtol is defined as taking
numbers starting with 0 as octal and 0x as hex. Getting around this
would require that Tcl change that fundamental definition, and you
wouldn't just want to change the compat function and use that because
that is guaranteed to confuse people seeing "strol" in C.

Personally, I never had the problem. C creates the base, perl and
Java recognize 0 for octals, it is just is one of those legacy things.

Jeffrey.Hobbs.vcf

Volker Hetzer

unread,
May 11, 1999, 3:00:00 AM5/11/99
to
Marco R. Gazzetta wrote:
>
> In article <3732EC89...@sni.de>,
> Volker Hetzer <hetze...@sni.de> wrote:
> > Bryan Oakley wrote:
> > > * list command changed to be of the major / minor type:
> > > - list index, list replace, etc instead of lindex, lreplace,
> > > etc.
> > > - the functionality of the existing list command (eg: [list
> > > a b c] would be replaced with [list create a b c]
> > Another question:
> > Should list create a data structure you can access with "list index $DATA 0"
> > or should it create a (possibly unnamed) list object you can query
> > ("$DATA index 0")?
> >
> > Greetings!
> > Volker
> But that's exactly what the compiler does!
>
> You send in a string and ask for an index? The string is transformed into a
> Tcl_ListObj and keeps running around that way until some evil villain makes
> it a string again (or a number, or whatever else comes to your mind).
>
> That's one of the major improvements the compiler brought.
>
> Marco

What I mean is not the internal representation, but the syntax.

$DATA index 0

was meant literally as a valid TCL script.

Greetings!
Volker

Jeffrey Hobbs

unread,
May 11, 1999, 3:00:00 AM5/11/99
to Duncan Barclay
Duncan Barclay wrote:
> - extend option get to allow the use of the option database to store
> values that can be looked up outside of the Tk core window context (i.e.
> allow
> set fred [option get *.foo.bar]

You mean so that it could be used in Tcl? You can already use it like:
>Main< () 3 % option add *[tk app].bar "my value"
>Main< () 4 % option get . bar [tk app]
my value

> - change the coordinate handling on canvas items from strings to
> lists so we don't have to do:

Actually, this could be done backwards-compatibly. Since no coords
command accepts just one arg (you need at least one x,y pair), you
could change coords to try and interpret one arg as a list. Otherwise
it has the default (current) behavior.

> - background stipples/pixmaps/bitmaps whatever for widgets (esp.

This is already in the dash patch, which would be nice to see
incrementally incorporated (full platform independence has to be
considered for all new functionality like this).

Jeffrey.Hobbs.vcf

Jeffrey Hobbs

unread,
May 11, 1999, 3:00:00 AM5/11/99
to Don Libes
Don Libes wrote:
> "Jeff Gosnell" <jmgo...@athena.louisville.edu> writes:
> > Paul Duffin wrote in message <373314...@mailserver.hursley.ibm.com>...
> > >Bryan Oakley wrote:
> > >> * anything that takes a numerical index should accept things
> > >> like "end - 1". (ala Jeff Hobbs' extended string command)
> > >
> > >If you are going to break compatability why not just say that
> > >negative indexes are relative to the length of the thing.
> > > -1 = end
> > > -2 = end - 1
> > >
> > >It would be simpler and quicker than parsing "end-1" although
> > >maybe not quite so readable.

> > imho, If you use {-1 = end} then that would lose some consistency on


> > what -1 means. Whenever I see -1, I think "Does not exist". i.e. [lsearch
> > $somelist $something] == -1, $something does not exist in $somelist.
>
> The solution is make lsearch (and others) return something else, like
> {} instead of -1. Returning -1 has always seemed kinda dumb to me.
> My code could just as easily check for "BOGUS" as "-1". I've never
> found any use for the coincidence that -1 appears to have some
> mathematical property.

In this case, it isn't just a mathematical property, but an int object.
However, whereas lsearch returns -1 to mean something doesn't exist,
doesn't mean that we can't use -int for back-indexing.

> In any case, I like Jeffrey's suggestion but I like the use of plain
> negative integers for reverse indexing even more. But then, this
> isn't new. I remember APL (25 years old now?) supported it. Now if
> only I could remember how APL indicated "element not found"....

My solution was actually easier, because it is isolated into the
TclGetIntForIndex that several string methods and list commands already
used. To change the interpretation of -int, you would have to go to
each individual command and do it. Ummm, not quite true, but in some
way yes.

To elaborate, TclGetIntForIndex is called with some kind of index format
(was "end" or int, now is "end?-int?" or int), and another number
specifying exactly what end translates to, and sets the interp'd value
into an index ptr.

Now take lindex. It takes this number, and if it is < 0, it just
returns. You can change TclGetIntForIndex such that when it receives
a -int (that isn't "end-int"), it would subtract from the end. This
saves the little extra processing playing around "end". However, now
you are saying that TclGetIntForIndex will never return an index < 0.

However, it is this subtle but important difference that makes it
hard to consider. What is -3 on a 2 element list? There it actually
is -1 and still returns empty. However, each command interprets the
out of range indices in its own way. That is not to say it can't be
done (very easy as stated above - about 3 lines of C), but you would
have to be very careful in wording the docs to not confuse anybody.
Also, I don't know what ramifications it would have on breaking
backwards compatibility (I never carelessly use -ints for indexing,
but...)

BTW, there is a precedence for this in Tcl - in the history command.

Jeffrey.Hobbs.vcf

Donal K. Fellows

unread,
May 11, 1999, 3:00:00 AM5/11/99
to
In article <7gvnk5$2jep$1...@computer.my.domain>,

Duncan Barclay <dm...@ragnet.demon.co.uk> wrote:
> My two penn'th is a few changes in Tk:
> - extend option get to allow the use of the option database to store
> values that can be looked up outside of the Tk core window context (i.e.
> allow
> set fred [option get *.foo.bar]

I would love it if support was added for the ? operator in option
definitions. Like that, I could specify options that apply to all
widgets at a known depth in the hierarchy without having to spell out
every excruciating step along the way or leaving an option way too
wide open. There should also be a mechanism for removing a particular
option from the database - some user settings (CDE fonts) are bogus
and non-useful altogether too often for my taste...

Oh, and tk_setPalette should set *Foreground and *Background as well
as *foreground and *background. Otherwise, settings from rubbish
systems like CDE can leak all over the place. This makes writing
consistent applications very difficult indeed.

These may sound like minor things, but they make a real difference and
having to work around them all the time is a complete pain...

Donal.
--
Donal K. Fellows http://www.cs.man.ac.uk/~fellowsd/ fell...@cs.man.ac.uk
-- The small advantage of not having California being part of my country would
be overweighed by having California as a heavily-armed rabid weasel on our
borders. -- David Parsons <o r c @ p e l l . p o r t l a n d . o r . u s>

Christopher Nelson

unread,
May 11, 1999, 3:00:00 AM5/11/99
to
Duncan Barclay wrote:
> - change the coordinate handling on canvas items from strings to
> lists so we don't have to do:
> canvas .c
> set item [.c create item rectangle 100 100 200 200]
> ...
> eval .c coords $item $x $y $x1 $y1

Maybe I've got my stoopid hat on this morning but what's the eval for?

> but just pass a list
> .c coords $item [list $x $y $x1 $y1]
> so it compiles.

Chris
--
Rens-se-LEER is a county. RENS-se-ler is a city. R-P-I is a school!

Christopher Nelson

unread,
May 11, 1999, 3:00:00 AM5/11/99
to
"Donal K. Fellows" wrote:
>
> In article <7gvnk5$2jep$1...@computer.my.domain>,
> Duncan Barclay <dm...@ragnet.demon.co.uk> wrote:
> > My two penn'th is a few changes in Tk:
> > - extend option get to allow the use of the option database to store
> > values that can be looked up outside of the Tk core window context (i.e.
> > allow
> > set fred [option get *.foo.bar]
>
> I would love it if support was added for the ? operator in option
> definitions. Like that, I could specify options that apply to all
> widgets at a known depth in the hierarchy without having to spell out
> every excruciating step along the way or leaving an option way too
> wide open. There should also be a mechanism for removing a particular
> option from the database - some user settings (CDE fonts) are bogus
> and non-useful altogether too often for my taste...
>
> Oh, and tk_setPalette should set *Foreground and *Background as well
> as *foreground and *background. Otherwise, settings from rubbish
> systems like CDE can leak all over the place. This makes writing
> consistent applications very difficult indeed.
>
> These may sound like minor things, but they make a real difference and
> having to work around them all the time is a complete pain...

Thinking of the backward compatibility concerns raised on this thread, I think
option suffers from (and is limited by) it's X heritage. What I'd like would be
a cross-platform way to store options that wasn't so limited. Maybe a protocol
for Tk to access the Windoze registry (that is, a defined set of keys that
widget .foo would look for and get options from) and a UNIX implementation of
the [registry] command.

Bryan Oakley

unread,
May 11, 1999, 3:00:00 AM5/11/99
to
Jeffrey Hobbs <Jeffre...@icn.siemens.de> wrote in message
news:3737E680...@icn.siemens.de...

> > <oak...@channelpoint.com> wrote:
> > > * treating numbers with leading zeros as octal has got to be
> > > replaced with something that requires an explicit action
> > > (eg: \0o012).

> Personally, I never had the problem. C creates the base, perl and


> Java recognize 0 for octals, it is just is one of those legacy things.

I've never had the problem either, that I recall. But a lot of people do,
and I'd wager very few (though certainly N>0) people actually make use of
this feature. Just yer basic burr under the saddle.


Roy Terry

unread,
May 11, 1999, 3:00:00 AM5/11/99
to
Yes,
Anyone who processes numbers put in by humans has the octal
avoidance
problem.

How about a switch in 8.x to turn octal interp off?

Roger E Critchlow Jr

unread,
May 11, 1999, 3:00:00 AM5/11/99
to
Christopher Nelson <ch...@pinebush.com> writes:

> Duncan Barclay wrote:
> > - change the coordinate handling on canvas items from strings to
> > lists so we don't have to do:
> > canvas .c
> > set item [.c create item rectangle 100 100 200 200]
> > ...
> > eval .c coords $item $x $y $x1 $y1
>
> Maybe I've got my stoopid hat on this morning but what's the eval for?

I suspect he forgot that he had a list of coordinates and wanted to expand
it into the call and wrote out the expanded list instead. You usually end
up writing something like this:

eval .c coords $item $list_of_x_and_y_pairs


-- rec --


Bruce S. O. Adams

unread,
May 11, 1999, 3:00:00 AM5/11/99
to

Christopher Nelson wrote:

That's a little sick. A system 'registry' in principle is a good thing but the M$
implementation leaves a lot to be desired. If you are going to use any kind of
'registry' it should be a distinct entity, stored perhaps in the relevant
installation
directory for each platform. I admit a UNIX 'registry' would be a good thing
for managing installs and the like, but the only time I would consider a UNIX
implementation of the M$ registry useful is in porting programs from Win32
to a different (desperating trying to resist the urge to say better :-) platform.
Actually, this is now done often enough for it to be worth distributing a TCL
implementation as a standard extension, though I'm sure other peoples efforts
are already available. The real difficulty with writing such a package is emulating

a fatal irreparable system crash on UNIX :-).
Regards,
Bruce A.


Nat Pryce

unread,
May 11, 1999, 3:00:00 AM5/11/99
to

"Bruce S. O. Adams" wrote:


> Christopher Nelson wrote:
> > Thinking of the backward compatibility concerns raised on this thread, I think
> > option suffers from (and is limited by) it's X heritage. What I'd like would be
> > a cross-platform way to store options that wasn't so limited. Maybe a protocol
> > for Tk to access the Windoze registry (that is, a defined set of keys that
> > widget .foo would look for and get options from) and a UNIX implementation of
> > the [registry] command.
>

> That's a little sick. A system 'registry' in principle is a good thing but the M$
> implementation leaves a lot to be desired. If you are going to use any kind of
> 'registry' it should be a distinct entity, stored perhaps in the relevant
> installation
> directory for each platform.

Actually, I've been thinking about this recently. It would
be great if Tcl had a standard package for storing and
retrieving installation-wide and per-user options for
applications that mapped onto the most appropriate mechanisms
for the platform.

On Unix it could map onto rc files in /usr/local/etc and in
each user's home directory, and maybe onto X resources.
On Windows it would map onto registry settings stored under the
\HKEY_LOCAL_MACHINE\Software and \HKEY_CURRENT_USER\Software keys.
A Mac user will have to tell us where options go on that platform.

Cheers,
Nat.

--
+------------------------------------------+---------------------+
| Name: Nat Pryce MEng ACGI | Dept. of Computing, |
| Email: n...@doc.ic.ac.uk | Imperial College, |
| Tel: +44 (0)171 594 8394 | 180 Queen's Gate, |
| Fax: +44 (0)171 581 8024 | London SW7 2BZ, |
| WWW: http://www-dse.doc.ic.ac.uk/~np2 | United Kingdom |
+------------------------------------------+---------------------+

Dan Curtiss

unread,
May 11, 1999, 3:00:00 AM5/11/99
to
Nat Pryce wrote:
> On Unix it could map onto rc files in /usr/local/etc and in
> each user's home directory, and maybe onto X resources.
> On Windows it would map onto registry settings stored under the
> \HKEY_LOCAL_MACHINE\Software and \HKEY_CURRENT_USER\Software keys.
> A Mac user will have to tell us where options go on that platform.

On the Mac it would be $env(PREF_FOLDER).

The method described above is how I manage multi-user preferences on
Unix, Windows, and Macs. The only platform that is difficult to manage
multi-user is Win 3.x...but, then that is basically unsupported by
anyone anymore. :)

-Dan

Bryan Oakley

unread,
May 11, 1999, 3:00:00 AM5/11/99
to
Roy Terry <royt...@earthlink.net> wrote in message
news:373840FA...@earthlink.net...

> Yes,
> Anyone who processes numbers put in by humans has the octal
> avoidance
> problem.

And people who have to parse dates of the form 01-01-1999, or 01/01/99

And people who have to parse zero-filled fixed length numeric formats (eg:
000000123).

> How about a switch in 8.x to turn octal interp off?

I would vote for it.

Donal K. Fellows

unread,
May 12, 1999, 3:00:00 AM5/12/99
to
In article <7ha0f3$17...@news2.newsguy.com>,
Bryan Oakley <oak...@channelpoint.com> wrote:

> Roy Terry <royt...@earthlink.net> wrote:
>> Yes, Anyone who processes numbers put in by humans has the octal
>> avoidance problem.
>
> And people who have to parse dates of the form 01-01-1999, or 01/01/99
> And people who have to parse zero-filled fixed length numeric formats (eg:
> 000000123).

I'm having a little trouble believing that everyone is clamouring for
this. We've got [scan $n %d n] which does quite a reasonable job
already, and when handling user-supplied numbers in C you always have
to go through a conversion anyway. (and strtol() takes a base
argument too...)

OK, so maybe a little conversion proc in the standard library would be
convenient, but anything else is just too likely to break existing
code. Backward compatability is not always best from a neatness PoV...

Roy Terry

unread,
May 12, 1999, 3:00:00 AM5/12/99
to
You mention scan, which is patterned after the old C functions
scanf, fscanf, etc. These functions don't octalize. So it was
even clear
way back in the seventies that numbers from the outside world
should
default to decimal. In this sense Tcl/Tk is _departing_ from
C-based practice.
Yes, I can live with unwanted octal conversions. I can live with
a lot
annoying historical happenstance. This seems to be one that could
be changed.
I would even call it low hanging fruit. I would like to see Tcl
more appealing
to new-comers. Not just "the natives".

Jeffrey Hobbs

unread,
May 12, 1999, 3:00:00 AM5/12/99
to Roy Terry
Roy Terry wrote:
> You mention scan, which is patterned after the old C functions
> scanf, fscanf, etc. These functions don't octalize. So it was even clear
> way back in the seventies that numbers from the outside world should
> default to decimal. In this sense Tcl/Tk is _departing_ from
> C-based practice.
> Yes, I can live with unwanted octal conversions. I can live with

Well, for the curious, the change would require replacing strtol and
the end checking with:
sscanf(str, "%d%c", &int, &dummychar) == 1

That says "see if we get an int and only an int", assuming we weren't
allowing whitespace to follow the int. I don't quite know what the
speed difference is from strtol and the pointer checking. However,
incorporating this would mean an incompatible change that wouldn't
be very easy to come to terms with, IMHO.

Jeffrey.Hobbs.vcf

Roy Terry

unread,
May 12, 1999, 3:00:00 AM5/12/99
to
[Several private e-mails pushed together]
How about instead a wrapper around strtol. If the "noOctal" flag
was set then the routine simply steps past any leading zeros
before
returning the result of calling strtol. If flag isn't set, then
immediately
call strtol.

Am I missing something?


Hobbs Jeffrey wrote:

> you set it through Tcl runtime, which means that a var
> lookup if due before each strtol. Hmmm, it may not be
> so bad, but it could be noticable.
>
I'm ignorant about internals, so I'm wondering: could a
write trace be put on the relevent tcl flag var which will
copy the value into an ordinary C static int only when it
changes?

Roy

lvi...@cas.org

unread,
May 12, 1999, 3:00:00 AM5/12/99
to

According to Donal K. Fellows <fell...@cs.man.ac.uk>:
:convenient, but anything else is just too likely to break existing

:code. Backward compatability is not always best from a neatness PoV...

It _may_ break _some_ code. How much code is the real issue. Which is
better - all current and future generations having to do calls to scan
to get rid of leading zeros, or all current and future generations having
to do some call to treat a string as octal? I would vote that the second
is better for the majority of users.

lvi...@cas.org

unread,
May 12, 1999, 3:00:00 AM5/12/99
to

According to Roy Terry <royt...@earthlink.net>:
:[Several private e-mails pushed together]

:How about instead a wrapper around strtol. If the "noOctal" flag
:was set then the routine simply steps past any leading zeros
:before
:returning the result of calling strtol. If flag isn't set, then
:immediately
:call strtol.

It's actually easier than that! If the flag is set, strtol is just
called with a base set to 10. The man page I have says that strtol
then treats the input number as a base 10 number.


$ cat to.c
#include <stdio.h>
#include <stdlib.h>

static char in[] = "008";
static char *ptr;

int main(int argc, char **argv)
{
(void) printf("%ld\n",strtol(in, &ptr, 10));
return 0;
}

$ cc to.c -o to
$ to
8

Donal K. Fellows

unread,
May 13, 1999, 3:00:00 AM5/13/99
to
In article <7hckg3$da4$1...@srv38s4u.cas.org>, <lvi...@cas.org> wrote:
> It's actually easier than that! If the flag is set, strtol is just
> called with a base set to 10. The man page I have says that strtol
> then treats the input number as a base 10 number.

But then you lose automagic 0x handling. What we really want is:

long strtol_magic(const char *str, char **endptr, int base) {
extern int noOctal;
if (base!=0 || noOctal!=0 || (str[0]=='0' && str[1]=='x')) {
return strtol(str, endptr, base);
} else {
return strtol(str, endptr, 10);
}
}

The above function always behaves exactly as the standard library
version except when the base is 0 (i.e. guess) and the (global)
noOctal flag is set and the string doesn't start with "0x", in which
case the contents of the string are always parsed as a decimal value.

The above code should be pretty much a drop-in replacement for the
standard version in all uses in the Tcl library (assuming that
strtol() is defined the same way everywhere... :^)

bo...@aol.com

unread,
May 16, 1999, 3:00:00 AM5/16/99
to
In article <3737E680...@icn.siemens.de>,
Jeffrey Hobbs <Jeffre...@icn.siemens.de> wrote:
> This is a multi-part message in MIME format.
> --------------742A4D744263A57456BB4BF0
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit

>
> Dave LeBlanc wrote:
> > <oak...@channelpoint.com> wrote:
> > > * treating numbers with leading zeros as octal has got to be
> > > replaced with something that requires an explicit action
> > > (eg: \0o012).
>
> > Yes please! Let's have decimal the implicit base for all unadorned
> > numbers.
>
> OK, this is something that some seem to want changed, but is *highly*
> unlikely to ever see changed, as it involves one of Tcl more deeply
> seated roots in C. People wonder why langauges adopt the conventions
> of C for integer formats... Well, if you are actually based on C, as
> Tcl is, and you don't create your own strtol (string to long)
function,
> than you inherit C's interpretation of integers.
>
> That is the case with Tcl. At its heart (in many places), it uses
> strtol as the "integer identifier". strtol is defined as taking
> numbers starting with 0 as octal and 0x as hex. Getting around this
> would require that Tcl change that fundamental definition, and you
> wouldn't just want to change the compat function and use that because
> that is guaranteed to confuse people seeing "strol" in C.
>
> Personally, I never had the problem. C creates the base, perl and
> Java recognize 0 for octals, it is just is one of those legacy things.
>
First lets take a look at why this is a problem for tcl programmers. It
isn't a problem for C because it is applied only to literals. In tcl,
substitution is performed on a variable expression to create a literal
expression. The resulting literal expression is evaluated by the expr
command. The expr command can only evaluate literal expressions. All
integer terms in tcl expressions are tested for leading zeros. So while
in C a programmer creates octal numbers explicitly with coded literals,
in tcl it is implicitly applied to all terms in an expression when the
expression is evaluated. Needless to say there is no utility in
applying radix conversions to all terms in expressions.

It can be argued that programmers should scan all numbers before using
if, expr, etc. but this slows down the programming process somewhat and
people(particularly newcomers) just forget to do it. When they do
forget it can be a bug that is waiting for the data that will make it
complain. More and more people are becoming programmers these days and
in the non-programmer community, leading zeros are simply trimmed.
(Please remember for a moment that it is the non-tcl-programmer
community that determines tcl's future growth.)

From a historical perspective it seems that this feature was implemented
out of expedience rather design. Now its argued that what was easy to
do and has been used for some time shouldn't be changed. At the time
this was done it was probably the right thing to do for an experimental
language. For the future, it isn't.

bob


--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---

Richard.Suchenwirth

unread,
May 18, 1999, 3:00:00 AM5/18/99
to
Bryan Oakley wrote:
>
> Ok, I thought it might be fun to discuss what the tcl communinity
> would like to see for tcl 9.0, since tcl 9.0 isn't even on the radar
> screen yet. Well, ok, I want to discuss what _I_ want to see for tcl
> 9.0. Feel free to tell me just how in the weeds I am.
>
> On my bike ride in to work today I was thinking about some of the
> warts on tcl (I hate it when I do that!) and thought maybe we should
> put forth a plan to remove them. The nutshell idea, then, is to define
> a slightly revised tcl language and introduce it as tcl 9.0.
>
>[snip++]

The people at Scriptics seem to be pretty busy in getting 8.0 and 8.1
running fine. And Tcl, as it is, IS a fine language. Many people in this
thread have proposed wishes what they'd like to have changed about Tcl
-- I'd like to point out that everybody can change "his" Tcl
(syntactically) if he feels like it.
Consider this code (dense because of heavy commenting):

#-------------- extended unknown handler: allow C-like constructs
if {[info proc _unknown]=={}} {rename unknown _unknown}
proc unknown {args} {
if [regexp (.+):$ [lindex $args 0] -> name] {
set args [lreplace $args 0 0 $name =]
} ;# allow REBOL-style assignments (foo: bar; bar: 17+4)
if {[lindex $args 1]=="="} {
# maybe an assignment like "x = 3+4" ? (Blanks matter!)
upvar [lindex $args 0] _x
set rest [lrange $args 2 end]
set _x $rest ;# this should always work...
catch {set _x [expr $rest]} ;# ...but maybe expr is happy
} elseif {[regexp {^([^ ]+)\+\+$} $args -> vname]} {
uplevel [list incr $vname] ;# allow things like "i++" ...
} elseif {[regexp {^([^ ]+)--$} $args -> vname]} {
uplevel [list incr $vname -1] ;# ... or "j--"
} else {eval _unknown $args} ;# let old "unknown" do it
}

This allows you to have C or even REBOL style assignments in your
7.x/8.x tclsh/wish without having to bother Scriptics, e.g.
% foo: hello world ;# == set foo "hello world"
hello world
% bar: 17+4 ;# does expr if possible without having to be told
21
% bar = 16+3
19
% bar = 16 + 30 ;# blanks matter only around the equal sign
46
% bar++ ;# == incr bar
47
% foo-- ;# try something bad -- incr will complain
error: expected integer but got "hello world"

Good thing: Everyone can rebuild the syntax as he pleases.
Bad thing: Reading (and editing) other people's code may get harder.
Conclusion: In serious apps, maybe don't do so. But the fact that it's
possible (and we have the freedom) is one of the Real Good Things about
Tcl.

--
Schoene Gruesse/best regards, Richard Suchenwirth -- tel. +49-7531-86
2703
> RC DT2, Siemens Electrocom GmbH, Buecklestr. 1-5, D-78467 Konstanz, Germany
> My opinions were not necessarily, or will not necessarily be, mine.

Reply all
Reply to author
Forward
0 new messages