[Request Tcl 8.1] Updated string command, take 2

2 views
Skip to first unread message

scriptic...@auto.genned.post

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

Tcl 8.1 Request: Generated by Scriptics' bug entry form at
http://www.scriptics.com/support/bugForm.html
Responses to this post are encouraged.
------

Submitted by: Jeffrey Hobbs
OperatingSystem: Sun Solaris
OperatingSystemVersion: 2.5.1
Synopsis: Updated string command, take 2

DesiredBehavior:
This is related to the previous feature request for an updated string
command, with one new method (string is) and patched against 8.1.0.

To cover it all again, I have made the following mods:

* string compare now takes optional length arg
(for strncmp behavior)

* added string equal (just a few lines of code blended
in with string compare)

* added string icompare/iequal for case-insensitive comparisons

* string index's index can now be ?end[+-]?expression
I made this change in the private TclGetIntForIndex,
which means that the list commands also benefit, as
well as string range, et al.

* added string is <class> ?-strict? ?-failindex varname? string
The following are valid classes:
alnum, alpha, ascii, boolean, digit, double, false,
integer, lower, space, true, upper, wordchar
Most of the correspond to the std is*() C functions. Those
that are missing (like iscntrl()) are due to a lack of
Tcl_UniCharIs*() equivalent, but could be added. I chose
not to mess with adding them, as that means going in and
setting things in the stub tables and such. However, they
are not complicated (zB, *IsControl() is a one liner).

Those that do not correspond to is*() (like boolean, int,
...) are intelligently handled to return the correct value,
but the command is written such that no type conversion of
the passed object occurs (a good thing, I believe). For
integer and double, this was tricky, but the test suite is
full, and the C code is well-commented with the purpose.

With the exception of int/double, which are inherently in
Tcl not unicode safe (still calls to strto*), all of these
are unicode safe (with tests).

* added [string repeat string count]
Repeats given string <count> number of times

* added string replace, quasi string equiv to lreplace
(quasi opposite of string range):
string replace first last ?string?
Example of use, replacing end of string with ...
should the string be more than 16 chars long:
string replace $string 16 end "..."
This just returns the string len < 16, so it
will only affect the long strings.

* added optional first and last args to string to*
This allows you to just affect certain regions of
a string with the command (like just capping the
first letter). I found the original totitle to
be too draconian to be useful.

* added [string map charMap string]
where charMap is a {from to from to} list that equates to
what one might get from [array get]. Each <from> and <to>
can be multiple chars (or none at all). For Tcl/CGI users,
this is a MAJOR speed booster.

Patch:
The patch comes to 100KB with full doc and test suite changes
against the Tcl 8.1.0 sources.
http://www.hobbs.wservice.com/tcl/capp/Tcl81-string.txt


PatchFiles:
C: tclUtil.c && tclCmdMZ.c
doc: string.n
tests: string.test cmd*.test l*.test error.test

Comments:
The implementations were done to maintain 100% backwards compatibility
with working code (changing the options to an arg can obviously change
what error strings arise), and reduce any loss of speed (the only
method that actually attained a speed loss was string index, as I
throw a Tcl_NumUtfChars call in to support end-1 like indices, and
that is not major).

Matt Newman

unread,
May 6, 1999, 3:00:00 AM5/6/99
to
I would like to add my support to aspects of this request - most of the
things Jeff has done are not only a good idea but will enable and range of
realworld activities to be done faster and cleaner.

However I would like to trim this back down to the "core" requirements, see
comments below.

scriptic...@auto.genned.post wrote in message
<3730753b$0$2...@nntp1.ba.best.com>...
>
>Submitted by: Jeffrey Hobbs


>Synopsis: Updated string command, take 2

[snip]

> * added string equal (just a few lines of code blended
> in with string compare)

Please don't add this, you can always do a compare against 0

To me it is
if {[string equal $str HELLO]} { ... }
VS
if {[string compare $str HELLO] == 0} {...}

>
> * added string icompare/iequal for case-insensitive comparisons

I think case-insensitive comparisions *must* be added to the core, but
......

I would rather see them added as options to "string compare" etc in the same
manner as other parts of Tcl/Tk
E.g.

set rc [string compare -nocase $str hello]


> * added optional first and last args to string to*
> This allows you to just affect certain regions of
> a string with the command (like just capping the
> first letter). I found the original totitle to
> be too draconian to be useful.

This is not required if "string replace" is implemented.

So whilst the following is nice:-

set nstr [string toupper $str 2 4]

The following is also quite fast and clean

set nstr [string replace $str 2 4 [string toupper [string range $str 2
4]]]


Matt Newman


Alexandre Ferrieux

unread,
May 6, 1999, 3:00:00 AM5/6/99
to
scriptic...@auto.genned.post wrote:
>
> the only
> method that actually attained a speed loss was string index, as I
> throw a Tcl_NumUtfChars call in to support end-1 like indices, and
> that is not major).

<hair-splitting>

By the way Jeff, by analogy with the text widget, why not use a *list*
(like {end - 1}) insetad of a packed string "end-1" ? This way you can
benefit from the integer representation of the Tcl_Obj 1 not being
lost...

</hair-splitting>

-Alex

Jeffrey Hobbs

unread,
May 6, 1999, 3:00:00 AM5/6/99
to Alexandre Ferrieux
Alexandre Ferrieux wrote:

> Jeffrey Hobbs wrote:
> > the only
> > method that actually attained a speed loss was string index, as I
> > throw a Tcl_NumUtfChars call in to support end-1 like indices, and
> > that is not major).

> By the way Jeff, by analogy with the text widget, why not use a *list*


> (like {end - 1}) insetad of a packed string "end-1" ? This way you can
> benefit from the integer representation of the Tcl_Obj 1 not being
> lost...

Well, actually the text widget isn't looking at that as a list, but
just throwing out whitespace as it goes along. end-1c, "end -1c" and
"end - 1 c" are all the same to the text widget.

Anyway, given the implementation, there would be no speed gain there,
*I think*. Before it was an expression, which doesn't gain with an
obj type anyway. However, Scott Stanton pointed out that one could do:
string index abc {end-[exit]}
and have an undesired side effect. Since I was only concerned with ints
(TclX had the expr syntax which I originally borrowed from), I changed
it to just read an int instead. If I were to adjust it to work with
a list coming in, I don't think the speed gained from being able to
pull out index 2 as an int will save overall on the extra processing
that would be required with the list.

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

Jeffrey.Hobbs.vcf

Alexandre Ferrieux

unread,
May 6, 1999, 3:00:00 AM5/6/99
to
Jeffrey Hobbs wrote:
>
> Alexandre Ferrieux wrote:
> > Jeffrey Hobbs wrote:
> > > the only
> > > method that actually attained a speed loss was string index, as I
> > > throw a Tcl_NumUtfChars call in to support end-1 like indices, and
> > > that is not major).
>
> > By the way Jeff, by analogy with the text widget, why not use a *list*
> > (like {end - 1}) insetad of a packed string "end-1" ? This way you can
> > benefit from the integer representation of the Tcl_Obj 1 not being
> > lost...
>
> Well, actually the text widget isn't looking at that as a list, but
> just throwing out whitespace as it goes along. end-1c, "end -1c" and
> "end - 1 c" are all the same to the text widget.

Ooops - you're right. My damned unreliable memory :)

> expr before

I agree, it was both an overkill and a dangerous thing.

> If I were to adjust it to work with
> a list coming in, I don't think the speed gained from being able to
> pull out index 2 as an int will save overall on the extra processing
> that would be required with the list.

Okay, it amounts to comparing [lindex] and sscanf("%d"). While I'm not
sure of the result, I agree that the overall gain to be expected is
small anyway !

Now while you're at it, could you also patch/override [lrange] and
[lindex] ? I find myself very often writing:

set short [lrange $long 0 [expr {[llength $long]-2}]]

While I'd love to write

set short [lrange $long 0 {end - 1}]

-Alex

Jeffrey Hobbs

unread,
May 6, 1999, 3:00:00 AM5/6/99
to Matt Newman
Matt Newman (courtesy cc) wrote:
> I would like to add my support to aspects of this request - most of the
> things Jeff has done are not only a good idea but will enable and range of
> realworld activities to be done faster and cleaner.

Keep "faster and cleaner" in mind for later...

> However I would like to trim this back down to the "core" requirements, see
> comments below.

> >Submitted by: Jeffrey Hobbs

> > * added string equal (just a few lines of code blended
> > in with string compare)
>
> Please don't add this, you can always do a compare against 0

> if {[string equal $str HELLO]} { ... }
> VS if {[string compare $str HELLO] == 0} {...}

At the moment, most people see [string match] as a counter to [string
comp],
and just take care to move the known string to the pattern arg, like so:
if {[string match HELLO $str]}
Why? Because it is logically very *clean* and easier to read than looking
at [str comp]==0. However, that has the danger of somebody accidentally
sticking something glob-like in the pattern arg, and is also >|< that much
slower. The [string equal] gets around the danger, and is *clean*.

Basically, since we don't want people making the mistake of doing:
$a == $b
for string comparisons, why make them do
[string compare $a $b]==0
instead of
[string equal $a $b]

> > * added string icompare/iequal for case-insensitive comparisons
>
> I think case-insensitive comparisions *must* be added to the core, but

> I would rather see them added as options to "string compare" etc in the same
> manner as other parts of Tcl/Tk

...


> set rc [string compare -nocase $str hello]

When you mention "other parts of Tcl/Tk", you have to take note that no
other string method takes -switches, which is why I avoided it to start
with. However, that doesn't mean it isn't the better way to go, and I
already went and broke that mold with [string is]. So, I've gone and
reworked the command as such:
string compare|equal ?-nocase? ?-length int? str1 str2

I will send this into Scriptics and we'll see what wins.

> > * added optional first and last args to string to*

> This is not required if "string replace" is implemented.


> So whilst the following is nice:-
> set nstr [string toupper $str 2 4]
> The following is also quite fast and clean
> set nstr [string replace $str 2 4 [string toupper [string range $str 2
> 4]]]

Faster? My timings show the first to be 35-40% faster.
Cleaner? The second runs through 3 string methods and a noticable amount
harder to read the first time through.

The arguments for keeping it down to a "core" are valid and good, which is
why I actually deferred other ideas that I'd seen. However, I think we've
seen enough parse fiddling in code and libraries because there are just a
few things that Tcl could still use. In the case of [string equal], I
would argue that it's a long term omission for a scripting language (we
don't and shouldn't all have to suffer with C-isms, which is exactly why
I made the mods to [string compare -nocase] as you rec'd). Besides, it is
only 4 lines of code to the core ([string equal] is, not -nocase).

The next thing on the hit list is of course lists. This is a little
trickier because I think further namespace pollution should be avoided
(in string, it was all just new methods). How that is "best" solved is
definitely debatable.

This all relates somewhat to the discussion about extending the catch
command. Sure, Tcl allows you to do some interesting things to build up
off primitives, but there is always a point where something is usefulness
enough that it belongs either in the Tcl kernel (that which is Tcl's
soul - string, expr, if, while, etc) or the Tcl core (all that surrounds
and ships with Tcl, but is more accesory - http, channels (some argue),
registry, dde, etc).

Some things can be more easily argued as a way for Tcl to wedge its way
into the hearts of a new niche of programmers. For example, if some of
the above string mods make future XML programmers happier about Tcl, then
they are worth their weight in cyberbits. However, I am sure there are
equally some things that are useless. What qualities would [string
reverse]
add to a language, other than knowing you have exceeded the kitchen sink?

I can't say that everything above is correct, but I did an analysis of my
code base (lots and lots o' Tcl) to see what I felt was missing, and would
really add value to the Tcl kernel.

Jeffrey.Hobbs.vcf

Jeffrey Hobbs

unread,
May 6, 1999, 3:00:00 AM5/6/99
to Alexandre Ferrieux
Alexandre Ferrieux wrote:
> > Alexandre Ferrieux wrote:
> > > Jeffrey Hobbs wrote:
> > > > throw a Tcl_NumUtfChars call in to support end-1 like indices, and
> > > > that is not major).

> Now while you're at it, could you also patch/override [lrange] and


> [lindex] ? I find myself very often writing:
> set short [lrange $long 0 [expr {[llength $long]-2}]]
> While I'd love to write
> set short [lrange $long 0 {end - 1}]

Oh, already done... ;^) Actually, that was part of changing the way
the string indices are calc'ed. In the core there is a TclGetIntForIndex
that interpreted "end" or integer. I changed it to be ?end[+-]?integer.
Since some list functions used it, it was automatically accepted there.
Then I just changed some of the string functions to use it as well.

Jeffrey.Hobbs.vcf

Alexandre Ferrieux

unread,
May 6, 1999, 3:00:00 AM5/6/99
to
Jeffrey Hobbs wrote:
>
> Alexandre Ferrieux wrote:
> > > Alexandre Ferrieux wrote:
> > > > Jeffrey Hobbs wrote:
> > > > > throw a Tcl_NumUtfChars call in to support end-1 like indices, and
> > > > > that is not major).
>
> > Now while you're at it, could you also patch/override [lrange] and
> > [lindex] ? I find myself very often writing:
> > set short [lrange $long 0 [expr {[llength $long]-2}]]
> > While I'd love to write
> > set short [lrange $long 0 {end - 1}]
>
> Oh, already done... ;^) Actually, that was part of changing the way
> the string indices are calc'ed. In the core there is a TclGetIntForIndex
> that interpreted "end" or integer. I changed it to be ?end[+-]?integer.
> Since some list functions used it, it was automatically accepted there.
> Then I just changed some of the string functions to use it as well.

Wow, great !!! Please please advertise this more. I believe it may
concern many more people than the [string] family does...

-Alex

Roy Terry

unread,
May 6, 1999, 3:00:00 AM5/6/99
to
Register 1 enthusiastic yes to the whole list of enhancements. To me they are
well balanced
between readability and efficiency. Excellent!
-Roy

scriptic...@auto.genned.post wrote:

> Tcl 8.1 Request: Generated by Scriptics' bug entry form at
> http://www.scriptics.com/support/bugForm.html
> Responses to this post are encouraged.
> ------
>
> Submitted by: Jeffrey Hobbs
> OperatingSystem: Sun Solaris
> OperatingSystemVersion: 2.5.1

> Synopsis: Updated string command, take 2
>

> DesiredBehavior:
> This is related to the previous feature request for an updated string
> command, with one new method (string is) and patched against 8.1.0.
>
> To cover it all again, I have made the following mods:
>
> * string compare now takes optional length arg
> (for strncmp behavior)
>

> * added string equal (just a few lines of code blended
> in with string compare)
>

> * added string icompare/iequal for case-insensitive comparisons
>

> * added optional first and last args to string to*

> This allows you to just affect certain regions of
> a string with the command (like just capping the
> first letter). I found the original totitle to
> be too draconian to be useful.
>

> * added [string map charMap string]
> where charMap is a {from to from to} list that equates to
> what one might get from [array get]. Each <from> and <to>
> can be multiple chars (or none at all). For Tcl/CGI users,
> this is a MAJOR speed booster.
>
>
>
> Patch:
> The patch comes to 100KB with full doc and test suite changes
> against the Tcl 8.1.0 sources.
> http://www.hobbs.wservice.com/tcl/capp/Tcl81-string.txt
>
> PatchFiles:
> C: tclUtil.c && tclCmdMZ.c
> doc: string.n
> tests: string.test cmd*.test l*.test error.test
>
>
>
> Comments:
> The implementations were done to maintain 100% backwards compatibility
> with working code (changing the options to an arg can obviously change

> what error strings arise), and reduce any loss of speed (the only


> method that actually attained a speed loss was string index, as I

Matt Newman

unread,
May 6, 1999, 3:00:00 AM5/6/99
to
Jeffrey Hobbs wrote in message <37317752...@icn.siemens.de>...

>Matt Newman (courtesy cc) wrote:
>> > * added string equal (just a few lines of code blended
>> > in with string compare)
>>
>> Please don't add this, you can always do a compare against 0
>> if {[string equal $str HELLO]} { ... }
>> VS if {[string compare $str HELLO] == 0} {...}
>
>At the moment, most people see [string match] as a counter to [string
>comp],
>and just take care to move the known string to the pattern arg, like so:
> if {[string match HELLO $str]}
>Why? Because it is logically very *clean* and easier to read than looking
>at [str comp]==0. However, that has the danger of somebody accidentally
>sticking something glob-like in the pattern arg, and is also >|< that much
>slower. The [string equal] gets around the danger, and is *clean*.
>
>Basically, since we don't want people making the mistake of doing:
> $a == $b
>for string comparisons, why make them do
> [string compare $a $b]==0
>instead of
> [string equal $a $b]
>

I buy this - plus the -nocase

>> > * added string icompare/iequal for case-insensitive comparisons
>>
>> I think case-insensitive comparisions *must* be added to the core, but
>> I would rather see them added as options to "string compare" etc in the
same
>> manner as other parts of Tcl/Tk
> ...
>> set rc [string compare -nocase $str hello]
>
>When you mention "other parts of Tcl/Tk", you have to take note that no
>other string method takes -switches, which is why I avoided it to start
>with. However, that doesn't mean it isn't the better way to go, and I
>already went and broke that mold with [string is]. So, I've gone and
>reworked the command as such:
> string compare|equal ?-nocase? ?-length int? str1 str2
>
>I will send this into Scriptics and we'll see what wins.


The -nocase should be available on all string sub-commands that utilize some
form of comparison:-

compare, match, and now equal

>> > * added optional first and last args to string to*
>
>> This is not required if "string replace" is implemented.
>> So whilst the following is nice:-
>> set nstr [string toupper $str 2 4]
>> The following is also quite fast and clean
>> set nstr [string replace $str 2 4 [string toupper [string range $str
2
>> 4]]]
>
>Faster? My timings show the first to be 35-40% faster.
>Cleaner? The second runs through 3 string methods and a noticable amount
>harder to read the first time through.


OK - I can see the argument that if you allow "string replace" which does an
intra-string update, then toupper and tolower should follow suit.


>The arguments for keeping it down to a "core" are valid and good, which is
>why I actually deferred other ideas that I'd seen. However, I think we've
>seen enough parse fiddling in code and libraries because there are just a
>few things that Tcl could still use. In the case of [string equal], I
>would argue that it's a long term omission for a scripting language (we
>don't and shouldn't all have to suffer with C-isms, which is exactly why
>I made the mods to [string compare -nocase] as you rec'd). Besides, it is
>only 4 lines of code to the core ([string equal] is, not -nocase).


There is one argument that I would like to highlight - stability of
interfaces. Everything you have indicated would be good, but people like
myself could not actually use these features since we need to support
production implementations that may be a few revs behind the curve. I guess
therefore I would prefer to see these kinds of changes added to a major
release level like 8.2 so I dont have to look at the minor levels p3, vs
8.0.3 etc to figure out which facilities I can use.


>The next thing on the hit list is of course lists. This is a little
>trickier because I think further namespace pollution should be avoided
>(in string, it was all just new methods). How that is "best" solved is
>definitely debatable.

What's wrong or difficient about the exisiting list commands, execept the
lack of the lassign, lmatch, lvarpop, lvarpush that TclX introduced and
which should IMNSHO be in the Core.

Matt Newman

Paul Duffin

unread,
May 6, 1999, 3:00:00 AM5/6/99
to
Matt Newman wrote:
>
> I would like to add my support to aspects of this request - most of the
> things Jeff has done are not only a good idea but will enable and range of
> realworld activities to be done faster and cleaner.
>
> However I would like to trim this back down to the "core" requirements, see
> comments below.
>
> scriptic...@auto.genned.post wrote in message
> <3730753b$0$2...@nntp1.ba.best.com>...
> >
> >Submitted by: Jeffrey Hobbs
> >Synopsis: Updated string command, take 2
> [snip]

>
> > * added string equal (just a few lines of code blended
> > in with string compare)
>
> Please don't add this, you can always do a compare against 0
>
> To me it is

> if {[string equal $str HELLO]} { ... }
> VS
> if {[string compare $str HELLO] == 0} {...}
>

string equality can be faster because you can compare pointer equality
first before comparing the contents. Considering the amount of code
required to implement this I would say go ahead.

> >
> > * added string icompare/iequal for case-insensitive comparisons
>
> I think case-insensitive comparisions *must* be added to the core, but

> ......


>
> I would rather see them added as options to "string compare" etc in the same
> manner as other parts of Tcl/Tk

> E.g.


>
> set rc [string compare -nocase $str hello]
>

> > * added optional first and last args to string to*

> > This allows you to just affect certain regions of
> > a string with the command (like just capping the
> > first letter). I found the original totitle to
> > be too draconian to be useful.
>

> This is not required if "string replace" is implemented.
>
> So whilst the following is nice:-
>
> set nstr [string toupper $str 2 4]
>
> The following is also quite fast and clean
>
> set nstr [string replace $str 2 4 [string toupper [string range $str 2
> 4]]]
>

The latter is probably an argument for adding it rather than not adding
it.

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

Christopher Nelson

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

Here's a loud vote FOR [string equal] for all the reasons Jeff put forth.
Thanks, Jeff!!

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

Cameron Laird

unread,
May 6, 1999, 3:00:00 AM5/6/99
to
In article <37317B9B...@icn.siemens.de>,
Jeffrey Hobbs <Jeffre...@icn.siemens.de> wrote:
>Alexandre Ferrieux wrote:
.
.

.
>> Now while you're at it, could you also patch/override [lrange] and
>> [lindex] ? I find myself very often writing:
>> set short [lrange $long 0 [expr {[llength $long]-2}]]
>> While I'd love to write
>> set short [lrange $long 0 {end - 1}]
>
>Oh, already done... ;^) Actually, that was part of changing the way
>the string indices are calc'ed. In the core there is a TclGetIntForIndex
>that interpreted "end" or integer. I changed it to be ?end[+-]?integer.
>Since some list functions used it, it was automatically accepted there.
>Then I just changed some of the string functions to use it as well.
.
.
.
Cool! This is getting to have a good aura.
I'm not sophisticated enough yet about bus-
iness to model what changes should be made
on a profit-loss basis, but I can guarantee
coders will use these enhancements a LOT.
--

Cameron Laird http://starbase.neosoft.com/~claird/home.html
cla...@NeoSoft.com +1 281 996 8546 FAX

Bruce S. O. Adams

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

Matt Newman wrote:There is one argument that I would like to highlight -
stability of

> interfaces. Everything you have indicated would be good, but people like
> myself could not actually use these features since we need to support
> production implementations that may be a few revs behind the curve. I guess
> therefore I would prefer to see these kinds of changes added to a major
> release level like 8.2 so I dont have to look at the minor levels p3, vs
> 8.0.3 etc to figure out which facilities I can use.
>

Nice set of enhancements by the way.
Good point about the patchlevel. Is there anyway the stubs mechanism or a
variation
thereof could be used to determine availability of features?

>
> >The next thing on the hit list is of course lists. This is a little
> >trickier because I think further namespace pollution should be avoided
> >(in string, it was all just new methods). How that is "best" solved is
> >definitely debatable.
>

> What's wrong or difficient about the exisiting list commands, execept the
> lack of the lassign, lmatch, lvarpop, lvarpush that TclX introduced and
> which should IMNSHO be in the Core.
>
> Matt Newman

I believe this was recently debated when someone posted a spec for a list
package recently. If you are out there how is it coming?
Regards,
Bruce A.


Don Porter

unread,
May 6, 1999, 3:00:00 AM5/6/99
to
Alexandre Ferrieux <alexandre...@cnet.francetelecom.fr> wrote:
> I find myself very often writing:
>
> set short [lrange $long 0 [expr {[llength $long]-2}]]
>
> While I'd love to write
>
> set short [lrange $long 0 {end - 1}]

Why not

set short [lreplace $long end end]

?

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

Jeffrey Hobbs

unread,
May 6, 1999, 3:00:00 AM5/6/99
to Matt Newman
Matt Newman wrote:
> Jeffrey Hobbs wrote in message <37317752...@icn.siemens.de>...
> >The arguments for keeping it down to a "core" are valid and good, which is
> >why I actually deferred other ideas that I'd seen. However, I think we've
> >seen enough parse fiddling in code and libraries because there are just a
> >few things that Tcl could still use. In the case of [string equal], I

> There is one argument that I would like to highlight - stability of


> interfaces. Everything you have indicated would be good, but people like
> myself could not actually use these features since we need to support
> production implementations that may be a few revs behind the curve. I guess
> therefore I would prefer to see these kinds of changes added to a major
> release level like 8.2 so I dont have to look at the minor levels p3, vs
> 8.0.3 etc to figure out which facilities I can use.

Yes, I consider this important as well. However, if it does manage to
appear in an interim release (say, 8.1.1), then those who want to bang
on it can, but others can wait until 8.2, where they know it will be a
nice, stable new feature.

> >The next thing on the hit list is of course lists. This is a little
> >trickier because I think further namespace pollution should be avoided
> >(in string, it was all just new methods). How that is "best" solved is
> >definitely debatable.
>

> What's wrong or difficient about the exisiting list commands, execept the
> lack of the lassign, lmatch, lvarpop, lvarpush that TclX introduced and
> which should IMNSHO be in the Core.

Well, you just answered your own question, from my view. I think lunique
needs to be added to that, and I'm sure there are a couple other ones with
a good argument behind them. However, I don't think it is a good idea to
just pop those in. First, since these are commands that many have used
(either through TclX, or a personal library), you don't want to put them
in the toplevel namespace for fear of naming conflicts (possibly one of
the more insidious backwards compatibility problems that will become more
prevalent as Tcl grows). But if they aren't directly in the top
namespace,
exactly what do you do with them, what do you name them?

Jeffrey.Hobbs.vcf

Alexandre Ferrieux

unread,
May 6, 1999, 3:00:00 AM5/6/99
to
Don Porter wrote:
>
> Alexandre Ferrieux <alexandre...@cnet.francetelecom.fr> wrote:
> > I find myself very often writing:
> >
> > set short [lrange $long 0 [expr {[llength $long]-2}]]
> >
> > While I'd love to write
> >
> > set short [lrange $long 0 {end - 1}]
>
> Why not
>
> set short [lreplace $long end end]

In this case, yes. But please generalize only a slight bit:

set short [lrange $long 0 {end - 3}]

See what I mean ? :)

-Alex

Paul Duffin

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

The Feather extension allows negative numbers as indeces and treats
them as offsets from [length].
-1 == end
-2 == end - 1

Unfortunately this mechanism can not be used in standard Tcl as it
would break existing scripts which relied on negative indeces being
normalised to 0.

Paul Duffin

unread,
May 6, 1999, 3:00:00 AM5/6/99
to
Jeffrey Hobbs wrote:
>
> Matt Newman wrote:
> > Jeffrey Hobbs wrote in message <37317752...@icn.siemens.de>...
> > >The arguments for keeping it down to a "core" are valid and good, which is
> > >why I actually deferred other ideas that I'd seen. However, I think we've
> > >seen enough parse fiddling in code and libraries because there are just a
> > >few things that Tcl could still use. In the case of [string equal], I
>
> > There is one argument that I would like to highlight - stability of
> > interfaces. Everything you have indicated would be good, but people like
> > myself could not actually use these features since we need to support
> > production implementations that may be a few revs behind the curve. I guess
> > therefore I would prefer to see these kinds of changes added to a major
> > release level like 8.2 so I dont have to look at the minor levels p3, vs
> > 8.0.3 etc to figure out which facilities I can use.
>
> Yes, I consider this important as well. However, if it does manage to
> appear in an interim release (say, 8.1.1), then those who want to bang
> on it can, but others can wait until 8.2, where they know it will be a
> nice, stable new feature.
>
> > >The next thing on the hit list is of course lists. This is a little
> > >trickier because I think further namespace pollution should be avoided
> > >(in string, it was all just new methods). How that is "best" solved is
> > >definitely debatable.
> >
> > What's wrong or difficient about the exisiting list commands, execept the
> > lack of the lassign, lmatch, lvarpop, lvarpush that TclX introduced and
> > which should IMNSHO be in the Core.
>
> Well, you just answered your own question, from my view. I think lunique
> needs to be added to that, and I'm sure there are a couple other ones with
> a good argument behind them. However, I don't think it is a good idea to
> just pop those in. First, since these are commands that many have used
> (either through TclX, or a personal library), you don't want to put them
> in the toplevel namespace for fear of naming conflicts (possibly one of
> the more insidious backwards compatibility problems that will become more
> prevalent as Tcl grows). But if they aren't directly in the top
> namespace,
> exactly what do you do with them, what do you name them?
>

Personally I think that any new commands which are added by the Tcl
code or the Tcl kernel should be in the ::tcl (or someother) namespace.
Scriptics need to understand that adding new functions in the global
namespace can break existing scripts, either because a
[namespace import] fails because the command to import already exists
or because the auto loader is not called.

Bryan Oakley

unread,
May 6, 1999, 3:00:00 AM5/6/99
to
Matt Newman <ma...@novadigm.com> wrote in message
news:7gr6aj$n0j$1...@ffx2nh3.news.uu.net...

> I would like to add my support to aspects of this request - most of the
> things Jeff has done are not only a good idea but will enable and range of
> realworld activities to be done faster and cleaner.

Ditto.

>
> However I would like to trim this back down to the "core" requirements,
see
> comments below.
>

> scriptic...@auto.genned.post wrote in message
> <3730753b$0$2...@nntp1.ba.best.com>...
> >
> >Submitted by: Jeffrey Hobbs
> >Synopsis: Updated string command, take 2
> [snip]
>

> > * added string equal (just a few lines of code blended
> > in with string compare)
>
> Please don't add this, you can always do a compare against 0
>

> To me it is


> if {[string equal $str HELLO]} { ... }
> VS
> if {[string compare $str HELLO] == 0} {...}

True. But I find the former more readable. And more readable means, to me
anyway, easier to maintain. According to Jeff the cost is negligable ("a few
lines of code") which seems like a good tradeoff to me.

>
> >
> > * added string icompare/iequal for case-insensitive comparisons
>
> I think case-insensitive comparisions *must* be added to the core, but
> ......
>
> I would rather see them added as options to "string compare" etc in the
same
> manner as other parts of Tcl/Tk
> E.g.
>
> set rc [string compare -nocase $str hello]

Yeah. I suggested that one too. Jeff seems to prefer the method he chose.
And since he's the one doing all the work, I'm not going to argue.

>
>
> > * added optional first and last args to string to*
> > This allows you to just affect certain regions of
> > a string with the command (like just capping the
> > first letter). I found the original totitle to
> > be too draconian to be useful.
>
> This is not required if "string replace" is implemented.
>
> So whilst the following is nice:-
>
> set nstr [string toupper $str 2 4]
>
> The following is also quite fast and clean
>
> set nstr [string replace $str 2 4 [string toupper [string range $str 2
> 4]]]

But not _as_ fast. I'm curious though -- how oftendoes one toupper or
tolower only a part of a string. I can't recall _ever_ doing it over the
last 15 years or so. I'm sure I must have, but it's a fairly rare occurance.
So in this case I'm not sure if we are buying much for the masses.

Bryan Oakley

unread,
May 6, 1999, 3:00:00 AM5/6/99
to
Matt Newman <ma...@novadigm.com> wrote:
> What's wrong or difficient about the exisiting list commands, execept the
> lack of the lassign, lmatch, lvarpop, lvarpush that TclX introduced and
> which should IMNSHO be in the Core.

string range
string replace
string index
string ...

vs.

lrange
lreplace
lindex
l....

One could argue that tcl would be a tad bit easier to learn if one could do

list range
list replace
list index
...

One could fairly easily change the API in pure tcl by creating a new list
command that uses the existing list command to accomplish the tasks, and add
a new subcommand "create" to do the work of the old list command (eg: [list
a b c] would be transformed to [list create a b c])

Backwards compatible? No. But a good change nonetheless, IMO. But it would
have to be an optional change through at least the next major change, or
maybe two. If done in a namespace, those of use who want to use the new
syntax could merely do something like this:

package require list
namespace import list::list

set foo [list create a b c]
...

Perhaps in later releases 'lreplace' and friends could all generate friendly
warnings that they are being deprecated and to use "list replace" instead.
One could very easily write a script that hunts all occurances down and
changes them.


Paul Duffin

unread,
May 6, 1999, 3:00:00 AM5/6/99
to
Bryan Oakley wrote:
>
> Matt Newman <ma...@novadigm.com> wrote:
> > What's wrong or difficient about the exisiting list commands, execept the
> > lack of the lassign, lmatch, lvarpop, lvarpush that TclX introduced and
> > which should IMNSHO be in the Core.
>
> string range
> string replace
> string index
> string ...
>
> vs.
>
> lrange
> lreplace
> lindex
> l....
>
> One could argue that tcl would be a tad bit easier to learn if one could do
>
> list range
> list replace
> list index
> ...
>
> One could fairly easily change the API in pure tcl by creating a new list
> command that uses the existing list command to accomplish the tasks, and add
> a new subcommand "create" to do the work of the old list command (eg: [list
> a b c] would be transformed to [list create a b c])
>

This is just what the Feather extension does.

> Backwards compatible? No. But a good change nonetheless, IMO. But it would
> have to be an optional change through at least the next major change, or
> maybe two. If done in a namespace, those of use who want to use the new
> syntax could merely do something like this:
>
> package require list
> namespace import list::list
>
> set foo [list create a b c]
> ...
>
> Perhaps in later releases 'lreplace' and friends could all generate friendly
> warnings that they are being deprecated and to use "list replace" instead.
> One could very easily write a script that hunts all occurances down and
> changes them.

In most cases yes, but I could probabl think of some pathological cases
where the extra space could cause problems

Paul Duffin

unread,
May 6, 1999, 3:00:00 AM5/6/99
to
Bryan Oakley wrote:
>
> Matt Newman <ma...@novadigm.com> wrote in message

> > This is not required if "string replace" is implemented.
> >
> > So whilst the following is nice:-
> >
> > set nstr [string toupper $str 2 4]
> >
> > The following is also quite fast and clean
> >
> > set nstr [string replace $str 2 4 [string toupper [string range $str 2
> > 4]]]
>
> But not _as_ fast. I'm curious though -- how oftendoes one toupper or
> tolower only a part of a string. I can't recall _ever_ doing it over the
> last 15 years or so. I'm sure I must have, but it's a fairly rare occurance.
> So in this case I'm not sure if we are buying much for the masses.

I think the range added to toupper is a much more sensible change than
simply adding a title method simply because it is more general and
therefore more useful.

Matt Newman

unread,
May 6, 1999, 3:00:00 AM5/6/99
to
Bryan Oakley wrote in message <7gsauj$i...@news1.newsguy.com>...

>
>One could argue that tcl would be a tad bit easier to learn if one could do
>
>list range
>list replace
>list index
>...
>
>One could fairly easily change the API in pure tcl by creating a new list
>command that uses the existing list command to accomplish the tasks, and
add
>a new subcommand "create" to do the work of the old list command (eg: [list
>a b c] would be transformed to [list create a b c])
>
>Backwards compatible? No. But a good change nonetheless, IMO. But it would
>have to be an optional change through at least the next major change, or
>maybe two. If done in a namespace, those of use who want to use the new
>syntax could merely do something like this:


Instead of calling it "list", what about calling it "llist" (bit too close
for comfort) or something else that is obvious but doesn't lead to
confusion.

Given the fact that "list' is as old as the hills overloading it would break
everything in a subtle hard-to-track down way.

Does anyone have any good ideas for a name, I can think of:

llist # don't really like this one too much.

tlist # less likely to get mixed up with list.

listcmd # not consistant with existing practice

lcmd # maybe

listop # maybe (i think my prev)

Anyway what is tricky here is not what it will do but what the damn name
should be!

Matt


Jeffrey Hobbs

unread,
May 6, 1999, 3:00:00 AM5/6/99
to Bryan Oakley
Bryan Oakley wrote:
> > set rc [string compare -nocase $str hello]
>
> Yeah. I suggested that one too. Jeff seems to prefer the method he chose.
> And since he's the one doing all the work, I'm not going to argue.

Well, the changes have been made for -nocase, and the old one actually
had some chance to get confused by unicode in conjunction with -length.
I have made all the corrections and sent Scriptics the changes.

> > So whilst the following is nice:-
> > set nstr [string toupper $str 2 4]
> > The following is also quite fast and clean
> > set nstr [string replace $str 2 4 [string toupper [string range $str 2
> > 4]]]
>
> But not _as_ fast. I'm curious though -- how oftendoes one toupper or
> tolower only a part of a string. I can't recall _ever_ doing it over the
> last 15 years or so. I'm sure I must have, but it's a fairly rare occurance.

Actually, the only reason I did it was for:
set capped [string toupper $str 0]
to avoid:
set capped [string toupper $str [string index $str 0]][string range $str
1 end]

That is the same as totitle, but it doesn't affect the capitalization of
the other letters. That's what I meant by "too draconian" before. Also,
I could see the above being useful in a text editor.

Jeffrey.Hobbs.vcf

lvi...@cas.org

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

According to Matt Newman <ma...@novadigm.com>:
:Jeffrey Hobbs wrote in message <37317752...@icn.siemens.de>...
:>The next thing on the hit list is of course lists. This is a little

:>trickier because I think further namespace pollution should be avoided
:>(in string, it was all just new methods). How that is "best" solved is
:>definitely debatable.
:
:What's wrong or difficient about the exisiting list commands, execept the

:lack of the lassign, lmatch, lvarpop, lvarpush that TclX introduced and
:which should IMNSHO be in the Core.


I don't speak for JH of course, but I interpreted his remarks to mean
that he would prefer not to create another 1/2 dozen or more l<something>
commands.

I myself would love to see a

list <method>

command that had methods such as assign, match, .... and which was
setup to make it easy to add new methods...
--
<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.

lvi...@cas.org

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

According to Paul Duffin <pdu...@mailserver.hursley.ibm.com>:
:Personally I think that any new commands which are added by the Tcl

:code or the Tcl kernel should be in the ::tcl (or someother) namespace.

And Tk commands should be in the ::tk namespace, etc. It seems to me
that would certainly be a good way to head.

Then to add Feather/curry/majorminor/some kind of hooks to be able to
add new methods to objects and commands...

Bruce S. O. Adams

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

Bryan Oakley wrote:

> Matt Newman <ma...@novadigm.com> wrote in message

> > set rc [string compare -nocase $str hello]
>
> Yeah. I suggested that one too. Jeff seems to prefer the method he chose.
> And since he's the one doing all the work, I'm not going to argue.
>
> >
> >

> > > * added optional first and last args to string to*
> > > This allows you to just affect certain regions of
> > > a string with the command (like just capping the
> > > first letter). I found the original totitle to
> > > be too draconian to be useful.
> >

> > This is not required if "string replace" is implemented.
> >

> > So whilst the following is nice:-
> >
> > set nstr [string toupper $str 2 4]
> >
> > The following is also quite fast and clean
> >
> > set nstr [string replace $str 2 4 [string toupper [string range $str 2
> > 4]]]
>
> But not _as_ fast. I'm curious though -- how oftendoes one toupper or
> tolower only a part of a string. I can't recall _ever_ doing it over the
> last 15 years or so. I'm sure I must have, but it's a fairly rare occurance.

> So in this case I'm not sure if we are buying much for the masses.

Happens more often than you might think. How about following a regexp
where you get the indices of the match out?

e.g.
set str "ProgramName: MiXeDcAsE"
regexp -indices "ProgramName: (\[^ \]+)" $str whole match
string toupper $str $match
puts $str
->
ProgramName: MIXEDCASE

Granted this smacks of sed and awk and horrible sorts of text manipulation jobs
that TCL would need better string commands to handle properly . . . :-)
The added overhead seems minimal next to the usefulness of the code. There's
nothing forcing you to use it. Filter it out in code review if you don't like it
:-)
(what's code review? - good question - very good question :-)
Regards,
Bruce A.


Bruce S. O. Adams

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

Paul Duffin wrote:

>
> The Feather extension allows negative numbers as indeces and treats
> them as offsets from [length].
> -1 == end
> -2 == end - 1
>
> Unfortunately this mechanism can not be used in standard Tcl as it
> would break existing scripts which relied on negative indeces being
> normalised to 0.
>

Slighty off topic aesthetics considerations:

Isn't this rather a sick behaviour to rely on. I know we encounter this
kind of thing all the time from our colleagues (and are even guilty of it
ourselves) but surely we shouldn't encourage it, or rather let people
get away with it. I someone is silly enough to use such a feature they
deserve all they get. I would prefer to add a flag that makes negative
indices produce an error instead. That way out of date code can be
pin-pointed for upgrade. Granted this means extra effort is required
to maintain code that must work with multiple TCL variants (often better
to have separate packages anyway). On the other hand end-1 et cetera
is much more explicit. What say you?
Regards,
Bruce A.

Bryan Oakley

unread,
May 6, 1999, 3:00:00 AM5/6/99
to
Matt Newman <ma...@novadigm.com>
[snip]

> Given the fact that "list' is as old as the hills overloading it would
break
> everything in a subtle hard-to-track down way.
>
> Does anyone have any good ideas for a name, I can think of:
>
> llist # don't really like this one too much.
>
> tlist # less likely to get mixed up with list.
>
> listcmd # not consistant with existing practice
>
> lcmd # maybe
>
> listop # maybe (i think my prev)

I say, damn backwards compatibility! (shameless plug for my new thread on
tcl 9.0 :-)

>
> Anyway what is tricky here is not what it will do but what the damn name
> should be!

Yep. I guess we could use "List", but that would stick out like a sore
thumb. Though perhaps we could create capitalized synonyms for all core
commands to make them stand out. But that would be a lot of pain and anguish
for (almost) nothing. I don't like that idea.

How about "elist", for "extended list"? A little footnote on the man page
could mention that the command isn't named "list" for historical reasons.

Don Porter

unread,
May 6, 1999, 3:00:00 AM5/6/99
to
Paul Duffin wrote:
>> The Feather extension allows negative numbers as indeces and treats
>> them as offsets from [length]. ...

>> Unfortunately this mechanism can not be used in standard Tcl as it
>> would break existing scripts which relied on negative indeces being
>> normalised to 0.

Bruce S. O. Adams <bruce...@rmc-ltd.com> wrote:
> Isn't this rather a sick behaviour to rely on. I know we encounter this
> kind of thing all the time from our colleagues (and are even guilty of it
> ourselves) but surely we shouldn't encourage it, or rather let people
> get away with it. I someone is silly enough to use such a feature they
> deserve all they get.

What?! Tcl programmers are to be punished for reading the docs and
relying on the behavior promised by them?

Consider this snippet for removing an item from a list, if present:

set idx [lsearch -exact $item $aList]
set aList [lreplace $aList $idx $idx]

You would prefer I explicitly test for -1 as a result of [lsearch]
and branch on that? I like it the way it is.

<...checks his facts before posting...>

Hmmm... It seems that behavior isn't documented in lreplace(n) after
all. In fact it changed between 7.4 and 7.5, as noted in the changes
file:

7/18/95 (bug fix) Changed "lreplace" so that nothing is deleted if
the last index is less than the first index or if the last index
is < 0.

<LITELLA>
Never mind.
</LITELLA>

Jeffrey Hobbs

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

> Matt Newman <ma...@novadigm.com> wrote:
> > What's wrong or difficient about the exisiting list commands, execept the
> > lack of the lassign, lmatch, lvarpop, lvarpush that TclX introduced and
> > which should IMNSHO be in the Core.
>
> string range
> string replace
> string ...
> vs.
> lrange
> lreplace
> l....

>
> One could argue that tcl would be a tad bit easier to learn if one could do
>
> list range
> list replace
> ...

Yeah, I'm of the same opinion. Unfortunately legacy issues tie us to the
former. You recommendations are exactly what I have considered (a list
namespace, or new list command as ::tcl::list). However, without knowing
the Scriptics mind on what would even have an inkling of getting included,
the different paths are enough of an effort to make one pause...

Jeffrey.Hobbs.vcf

Eugene Lee

unread,
May 7, 1999, 3:00:00 AM5/7/99
to
In article <3730753b$0$2...@nntp1.ba.best.com>,

<scriptic...@auto.genned.post> wrote:
>
>Tcl 8.1 Request: Generated by Scriptics' bug entry form at
> http://www.scriptics.com/support/bugForm.html
>Responses to this post are encouraged.
>------

Some of these features are already implemented in TclX.

> * added string equal (just a few lines of code blended
> in with string compare)

See 'cequal'.

> * string index's index can now be ?end[+-]?expression

See 'cindex'. But what's the purpose of '?end+?expression', since
there seems little point in finding the string index when the index
itself exceeds the string length?

> * added string is <class> ?-strict? ?-failindex varname? string

This looks a lot like 'ctype'.

> * added [string repeat string count]
> Repeats given string <count> number of times

See 'replicate'.

On the whole, I like many of the ideas you've suggested. And if some
of the ideas were indeed inspired by TclX, it'd be nice to acknowledge
that too.

These are my opinions only. I'm no official speaker for my employer,
nor for TclX.


--
Eugene Lee
Systems Administrator
NeoSoft R&D Department
eug...@neosoft.com
--
Eugene Lee
Systems Administrator
NeoSoft R&D Department
eug...@neosoft.com

Jeffrey Hobbs

unread,
May 7, 1999, 3:00:00 AM5/7/99
to Eugene Lee
Eugene Lee wrote:
> >Tcl 8.1 Request: Generated by Scriptics' bug entry form at
> > http://www.scriptics.com/support/bugForm.html
> >Responses to this post are encouraged.

> Some of these features are already implemented in TclX.

That they are, and it was definitely a source of inspiration,
and in some cases code (although that had to be redone for
various reasons). Mark is already aware of this, as I have
traded some mail about it with him (regarding unicode and TclX),
but let's all give Karl a big smile too:
== ==
0 0
/\
\____/

> > * string index's index can now be ?end[+-]?expression
>
> See 'cindex'. But what's the purpose of '?end+?expression', since

There is no need in the plus, and actually it is no longer an expression,
as it was pointed out that {end-[exit]} might not be desirable. I had
adopted this from TclX, but it is now just ?end-?integer.

> > * added string is <class> ?-strict? ?-failindex varname? string
>
> This looks a lot like 'ctype'.

That it is, although ctype had a few more things, although "is" has a
few other things. The big difference is that this is now 100% unicode
safe, along with the other new commands (Mark is stil ironing out the
unicode for TclX8.1). The things like "is control" can be added, they
just need a few more lines of code in tclUtf.c.

> On the whole, I like many of the ideas you've suggested. And if some
> of the ideas were indeed inspired by TclX, it'd be nice to acknowledge

See above. More than this has come out of TclX, because Mark and Karl
have been good at pinpointing and providing extra useful bits to Tcl
(which all came out of what they needed, of course).

Jeffrey.Hobbs.vcf

Christopher Nelson

unread,
May 7, 1999, 3:00:00 AM5/7/99
to
Bryan Oakley wrote:
> > Anyway what is tricky here is not what it will do but what the damn name
> > should be!
>
> Yep. I guess we could use "List", but that would stick out like a sore
> thumb. Though perhaps we could create capitalized synonyms for all core
> commands to make them stand out. But that would be a lot of pain and anguish
> for (almost) nothing. I don't like that idea.
>
> How about "elist", for "extended list"? A little footnote on the man page
> could mention that the command isn't named "list" for historical reasons.

I'll buy it.

Paul Duffin

unread,
May 7, 1999, 3:00:00 AM5/7/99
to
Jeffrey Hobbs wrote:
>
> Bryan Oakley wrote:
> > Matt Newman <ma...@novadigm.com> wrote:
> > > What's wrong or difficient about the exisiting list commands, execept the
> > > lack of the lassign, lmatch, lvarpop, lvarpush that TclX introduced and
> > > which should IMNSHO be in the Core.
> >
> > string range
> > string replace
> > string ...
> > vs.
> > lrange
> > lreplace
> > l....
> >
> > One could argue that tcl would be a tad bit easier to learn if one could do
> >
> > list range
> > list replace
> > ...
>
> Yeah, I'm of the same opinion. Unfortunately legacy issues tie us to the
> former. You recommendations are exactly what I have considered (a list
> namespace, or new list command as ::tcl::list). However, without knowing
> the Scriptics mind on what would even have an inkling of getting included,
> the different paths are enough of an effort to make one pause...
>

I would go for adding a list command into ::tcl and allowing the user
to decide whether to import it or not. Maybe it should be packaged up
into a "Tcl::List" package. I do not like the idea of having a
::list::xxx format as it does not fit in with the way things are
currently done.

Scott Stanton

unread,
May 7, 1999, 3:00:00 AM5/7/99
to
Jeffrey Hobbs wrote:
>
> Eugene Lee wrote:

> > On the whole, I like many of the ideas you've suggested. And if some
> > of the ideas were indeed inspired by TclX, it'd be nice to acknowledge
>
> See above. More than this has come out of TclX, because Mark and Karl
> have been good at pinpointing and providing extra useful bits to Tcl
> (which all came out of what they needed, of course).

There is a long tradition of incredibly useful pieces of TclX finding their way
into the core. I'd like to see more of it happen, and Jeff's work with the new
string subcommands is a great step in that direction.

Now, to the topic of how best to add new "list" functionality:

The two issues that are foremost in our thinking here at Scriptics are
compatibility and simplicity. These are often incompatible goals, so the
challenge is to find the right balance.

At this point, changing existing interfaces in incompatible ways has an
extremely high cost, so I don't think we can do anything that changes the
"list" command. Adding new commands is much easier, so I'd argue for that.
From a clarity standpoint, I'd like to see the list commands appear as new
commands in a namespace that gathers all of the list manipulation commands, but
there are drawbacks to this approach.

There's always a trade off between putting things into a namespace and treating
them like separate packages and putting them into the global namespace and
treating them as an integral part of the language. Things that live in the
global namespace are immediately available from any namespace. If every bit of
code ends up importing utility functions into either the global scope or every
individual namespace, then it's not clear you've actually bought anything but
increased complexity by moving the commands out of the global scope in the
first place.

There are a group of commands that essentially every piece of Tcl code ends up
needing access to (e.g. "set", "if", "return"). While we could put those
commands into a ::tcl namespace, I think in practice they'll immediately get
imported back into the global namespace. For compatibility reasons, we'd need
to do that importing automatically, so I'm not sure there's a lot of benefit to
creating the extra namespace.

Certainly any time someone is adding a totally new subsystem, it would be best
to make it a loadable package with its own namespace. For things that are
incremental improvements to existing systems, the answer is less clear. I
don't think we've really determined what the best approach is yet, so we'll
probably have to evaluate things on a case by case basis.
___________________________________________________________
Scott Stanton 650-210-0105 tel
Sr. Software Engineer 650-210-0101 fax
Scriptics Corporation scott....@scriptics.com
The Tcl Platform Company http://www.scriptics.com

Andreas Kupries

unread,
May 7, 1999, 3:00:00 AM5/7/99
to
"Bruce S. O. Adams" <bruce...@rmc-ltd.com> writes:

> Matt Newman wrote:There is one argument that I would like to highlight -
> stability of

> > >The next thing on the hit list is of course lists. This is a little


> > >trickier because I think further namespace pollution should be avoided
> > >(in string, it was all just new methods). How that is "best" solved is
> > >definitely debatable.
> >

> > What's wrong or difficient about the exisiting list commands, execept the
> > lack of the lassign, lmatch, lvarpop, lvarpush that TclX introduced and
> > which should IMNSHO be in the Core.
> >

> > Matt Newman
>
> I believe this was recently debated when someone posted a spec for a list
> package recently. If you are out there how is it coming?

Progress is currently infinitesimal. Got sidetracked by other things
way to often. It is not forgotten though.

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

Chang LI

unread,
May 8, 1999, 3:00:00 AM5/8/99
to
Jeffrey Hobbs wrote:
>

Is it available as a loadable extension?

--------------------------------------------------------------
Chang LI, Neatware
email: cha...@neatware.com
--------------------------------------------------------------

Roger E Critchlow Jr

unread,
May 8, 1999, 3:00:00 AM5/8/99
to
"Matt Newman" <ma...@novadigm.com> writes:

> Bryan Oakley wrote in message <7gsauj$i...@news1.newsguy.com>...

[ ... ]


> Does anyone have any good ideas for a name, I can think of:
>
> llist # don't really like this one too much.
>
> tlist # less likely to get mixed up with list.
>
> listcmd # not consistant with existing practice
>
> lcmd # maybe
>
> listop # maybe (i think my prev)
>

> Anyway what is tricky here is not what it will do but what the damn name
> should be!

Call it a sequence.

-- rec --


John Ousterhout

unread,
May 8, 1999, 3:00:00 AM5/8/99
to
Bryan Oakley wrote:
>
> Matt Newman <ma...@novadigm.com> wrote:
> > What's wrong or difficient about the exisiting list commands, execept the
> > lack of the lassign, lmatch, lvarpop, lvarpush that TclX introduced and
> > which should IMNSHO be in the Core.
>
> string range
> string replace
> string index

> string ...
>
> vs.
>
> lrange
> lreplace
> lindex

> l....
>
> One could argue that tcl would be a tad bit easier to learn if one could do
>
> list range
> list replace
> list index
> ...

Yes, I agree. Many years ago, when the current set of list commands was
added to Tcl, there was a big discussion about whether they should take
the form they currently have, or be options to a single "list" command.
At
the time I was actually in favor of using the
single-command-with-options
form, but other people argued for the current form and I eventually gave
in. In retrospect, I wish I hadn't.

Unfortunately, I don't think it's reasonable to redefine the "list"
command at this point. It would just break too many scripts. I suppose
an alternative would be to define a new command, such as "l" or "lop",
but the current usage is so ingrained that I'm not sure we'd be able
to convert people over.
________________________________________________________________________
John Ousterhout 650-210-0102 tel
Chief Executive Officer 650-210-0101 fax
Scriptics Corporation john.ou...@scriptics.com

John Ousterhout

unread,
May 8, 1999, 3:00:00 AM5/8/99
to
The question of whether to add new core Tcl features in namespaces or
in the global namespace is a tricky one, and I think there are good
arguments on each side. However, I mostly agree with Scott Stanton.

At this point, I'd argue that any core Tcl features (where "core Tcl"
means something that's in the core releases and is also widely used)
should just go in the global namespace. My argument is based mostly
on consistency and historical tradition. Having a "::tcl" namespace
will be confusing (some things will be in it and some won't, all for
historical reasons) so most people will end up importing everything
from "::tcl" into the global namespace, which defeats the whole
purpose.

On the other hand, I would argue that new library procedures that
are more specialized could easily go in a namespace. For example,
the auto-loading library procedures would fit this category, if they
were being developed today.

I also see the point about implementing tons of new list commands
and thereby generating conflicts in the global namespace. Perhaps
this would argue for a "lop" command that contains any new list
commands, or perhaps all the list commands altogether.

Spiros J. Boucouris

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

The problem of global vs namespace will have to be dealt with anyway.
The main offender right now (IMHO) is Tk (dozens of utility and widget
commands). I propose that Tk be given its own "global" namespace(s)
to at least separate things. Such "global" namespaces would act as if
they were part of the global namespace thus saving the need of
forever importing things. Under such a scheme we could have ::tcl,
::tk and ::tkwidgets, with :: appearing as the union of the three.

Please note that I am not suggesting making this kludge a part of
the language, just a way to grandfather Tk while cleaning things up.
"global" namespaces should only be created by the core Tcl team
and then with great care.

I believe that grandfathering can also be used for the list commands.
Assuming the unified-list-command, henceforth "unilist", supports
(in addition to its own syntax), all the present list commands as options.
So 'unilist lappend ...' is equivalent to 'lappend ...'. This would provide
an easy way to maintain backward compatibility, a simple sed script could
be used to migrate, and you could probably move the present list commands
into a "global" namespace, say ::deprecated.

Bob Techentin

unread,
May 10, 1999, 3:00:00 AM5/10/99
to
Matt Newman wrote:
>
> Given the fact that "list' is as old as the hills overloading it would break
> everything in a subtle hard-to-track down way.
>
> Does anyone have any good ideas for a name, I can think of:
>
> llist # don't really like this one too much.
>
> tlist # less likely to get mixed up with list.
>
[snip]

I vote for the namespace:

::list::create
::list::append
::list::insert
::list::range
::list::replace
::list::remove
::list::multisearch
::list::reverse
::list::apply

Bob
--
Bob Techentin techenti...@mayo.edu
Mayo Foundation (507) 284-2702
Rochester MN, 55905 USA http://www.mayo.edu/sppdg/sppdg_home_page.html

lvi...@cas.org

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

According to John Ousterhout <ous...@scriptics.com>:
:command at this point. It would just break too many scripts. I suppose

:an alternative would be to define a new command, such as "l" or "lop",
:but the current usage is so ingrained that I'm not sure we'd be able
:to convert people over.


If all the new operator provided was the current list operations, then
I suspect that you are right.

However, if the new operator provided extended functionality, as well
as the current functionality, then I believe that people would begin
the transition.

Robert Seeger

unread,
May 11, 1999, 3:00:00 AM5/11/99
to
Come people have commented on the fact that having a ::list namespace
may cause confusion. As a way to avoid this confusion, perhaps we could
consider ::ListOps:: (obviously stolen from the recently released SetOps
package), for the name of the namespace.

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

Jeffrey Hobbs

unread,
May 12, 1999, 3:00:00 AM5/12/99
to John Ousterhout
John Ousterhout wrote:
> Bryan Oakley wrote:
> > lrange
> > lreplace

> > l....
> >
> > One could argue that tcl would be a tad bit easier to learn if one could do
> >
> > list range
> > list replace
> > ...

...[history of list command origination]...

> Unfortunately, I don't think it's reasonable to redefine the "list"

> command at this point. It would just break too many scripts. I suppose
> an alternative would be to define a new command, such as "l" or "lop",
> but the current usage is so ingrained that I'm not sure we'd be able
> to convert people over.

Oh, I think it would be quite easy. Introduce a list command that
*supercedes* all current list ops. While it would, due to historical
reasons, be called "elist", "l" or "lop", if it had all the functions
of the current list commands, plus commonly used extension list commands
(see TclX and the like - lunique, lmatch, lunion come to mind top), and
people would see that as the first and last stop for list functions.

Another problem with the current l* functions that I have seen often in
the newsgroup, is that for some beginners, most notoriously those who
obtained Tcl but not a Tcl book, overlook some or all of the current
list functions because there aren't simply listed under "list" in the
provided docs. Sometimes you have to know the name before you get to
the docs for it. With "string", people look up "string" and get all
(almost) the string primitive ops. In this way, a new list op would
gain from being the doc source.

Furthermore, in the event that "lop" would be put in place (say 9.0),
you could deprecate l* with simple aliases to the lop methods:
interp alias {} lappend {} lop append

Jeffrey.Hobbs.vcf

Paul Duffin

unread,
May 17, 1999, 3:00:00 AM5/17/99
to
Robert Seeger wrote:
>
> Come people have commented on the fact that having a ::list namespace
> may cause confusion. As a way to avoid this confusion, perhaps we could
> consider ::ListOps:: (obviously stolen from the recently released SetOps
> package), for the name of the namespace.
>

In that case why not just create a command called [listops ...] which
would be more in tune with existing commands.

> Rob Seeger
>
> Bob Techentin wrote:
> >
> > Matt Newman wrote:
> > >
> > > Given the fact that "list' is as old as the hills overloading it would break
> > > everything in a subtle hard-to-track down way.
> > >
> > > Does anyone have any good ideas for a name, I can think of:
> > >
> > > llist # don't really like this one too much.
> > >
> > > tlist # less likely to get mixed up with list.
> > >
> > [snip]
> >
> > I vote for the namespace:
> >
> > ::list::create
> > ::list::append
> > ::list::insert
> > ::list::range
> > ::list::replace
> > ::list::remove
> > ::list::multisearch
> > ::list::reverse
> > ::list::apply
> >

--

Reply all
Reply to author
Forward
0 new messages