arrays really aren't

2 views
Skip to first unread message

Bryan Kelly

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

Are there really arrays in tcl. I don't think there are. Does any one have
an explanation?

Elaboration:
I am using tcl through expect. In trying to work with arrays, I have come
to the conclusion that arrays are not really arrays. they are really a
collection of similiar named variables. I was trying to declare an array
globaly, and it just didn't work. I tired to use an array with the
"fornext" consctuct, but that doesn't work. (I concluded that fornext is for
lists only)

I find that the book "Exploring Expect" may be okay for non programmers, but
it leaves out one heck of a lot that causes programmers to leap to inproper
conclusions and get scrwed up.

Here is a short script that I used in messing around with this problem.
This is about the 40th generation, but you should get the idea of what I was
trying to do.

Thanks for your time,
Bryan


## An array test


proc populate_array { }

global ip_address(0)
global ip_address(1)
global ip_address

set ip_address(0) "163.206.64.185"
set ip_address(1) "163.206.64.186"

}
set ip_address(0) "junk"
send_user "\n calling proc next "

populate_array

send_user "\n item is $ip_address(0) "
for { set i 0 } { $i <= 1 } { incr i } {
send_user "\n check item $i next "
send_user "\n item $i is $ip_address($i) "
}


Bryan Oakley

unread,
May 11, 1999, 3:00:00 AM5/11/99
to
Bryan Kelly <kel...@brevard.net> wrote in message
news:CB1_2.3413$LP2....@news6.ispnews.com...

>
> Are there really arrays in tcl. I don't think there are. Does any one
have
> an explanation?

Well, actually arrays _aren't_ arrays so much as they are very handy hash
tables. But, one can use them like an array without having to worry about
the distinction.

>
> Elaboration:
[snip]


> ## An array test
>
>
> proc populate_array { }
>
> global ip_address(0)
> global ip_address(1)

These two are completely unnecessary and may actually cause problems. I've
never actually explored this particular edge case of declaring the whole
array global as well as individual elements.

> global ip_address

This is the way to do it to declare a whole array as global.

> [snip]

The rest of the code seems reasonable. I'm not sure where the problem lies.

By the way, foreach (you say 'fornext', but I assume you meant 'foreach')
works just fine with arrays, but you have to know precisely how foreach
works. It takes as it's second argument a list. Fortunately, we can get a
well formed list of array element names using [array names]. So, pairing
them together we get something like this to loop over each element in the
array:

foreach element [array names ip_address] {
send_user "\n item is $ip_address($element)
}

Bryan Kelly

unread,
May 11, 1999, 3:00:00 AM5/11/99
to
Oops, I replied to sender rather than to group. Lets try this again.

> global ip_address

>>This is the way to do it to declare a whole array as global.

The problem I see is that when I do this, then I return back into the mail
program with
send_user "\n value is $ip_address(1) "
It tells that this doesn't exist. With this response, I conclude that
there are no arrays.

To recap, declare an array, populate it in a procedure, then show the
contents back in
the main function.

I will look at the foreach and see if I can understand this.

Thanks for your reply,
Bryan


sanjay...@my-dejanews.com

unread,
May 12, 1999, 3:00:00 AM5/12/99
to
In article <7i4_2.1252$G3.3...@news14.ispnews.com>,
"Bryan Kelly" <kel...@brevard.net> wrote:

> It tells that this doesn't exist. With this response, I conclude
that
> there are no arrays.
>
> To recap, declare an array, populate it in a procedure, then show the
> contents back in
> the main function.
>

I don't see any problem. Run the following code.
the output is

192.168.0.19
192.168.0.29
192.168.0.39

which means u can define new elements anywhere.
-----------------------------------------------
proc Change_address {} {
global ip_address

set ip_address(0) "192.168.0.19"
set ip_address(1) "192.168.0.29"
set ip_address(leto) "192.168.0.39"


}

set ip_address(0) "192.168.0.1"
Change_address
foreach address [array names ip_address] {
puts $ip_address($address)
}
--------------------------------------------

- Sanjay


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

Jonathan Cook

unread,
May 12, 1999, 3:00:00 AM5/12/99
to
On Mon, 10 May 1999 18:30:09 -0400 it appears that Bryan Kelly (kel...@brevard.net) wrote:
:
: I have come

: to the conclusion that arrays are not really arrays. they are really a
: collection of similiar named variables.

Umm, technically, that's what arrays are in any language. Most languages
restrict the "index" part of the name to be an integer. Tcl doesn't.

: I was trying to declare an array


: globaly, and it just didn't work.

: proc populate_array { }
:
: global ip_address(0)
: global ip_address(1)
: global ip_address

I thought for a minute you might have found a bug -- since you only
need to declare the array name as global, not each element. But, what
you actually have is a missing brace to open the procedure body. I
replaced your proc line with a correct one:

"proc populate_array { } {"

and defined "send_user" to be "puts" (messed up with braces, however),
and your script worked just fine:

% proc populate_array { } {

global ip_address(0)
global ip_address(1)
global ip_address

set ip_address(0) "163.206.64.185"
set ip_address(1) "163.206.64.186"

}
% set ip_address(0) "junk"
junk
% proc send_user {args} { puts $args }
% send_user "\n calling proc next "
{
calling proc next }
% populate_array
163.206.64.186
%
% send_user "\n item is $ip_address(0) "
{
item is 163.206.64.185 }
% for { set i 0 } { $i <= 1 } { incr i } {


send_user "\n check item $i next "
send_user "\n item $i is $ip_address($i) "
}

{
check item 0 next }
{
item 0 is 163.206.64.185 }
{
check item 1 next }
{
item 1 is 163.206.64.186 }
%

JonCook.

lvi...@cas.org

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

According to Bryan Kelly <kel...@brevard.net>:
:Here is a short script that I used in messing around with this problem.

:This is about the 40th generation, but you should get the idea of what I was
:trying to do.

Here's a modified version of what you were trying to do:

proc populate_array { } {

global ip_address

set ip_address(0) "163.206.64.185"
set ip_address(1) "163.206.64.186"

}
set ip_address(0) "junk"
puts "\n calling proc next "

populate_array

puts "\n item is $ip_address(0) "


for { set i 0 } { $i <= 1 } { incr i } {

puts "\n check item $i next "
puts "\n item $i is $ip_address($i) "
}

-----------

I used puts instead of send_user so that the code is strictly Tcl.

When I run the above code, I get:

calling proc next

item is 163.206.64.185

check item 0 next

item 0 is 163.206.64.185

check item 1 next

item 1 is 163.206.64.186


What were you expecting to happen?
--
<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.

Phil

unread,
May 12, 1999, 3:00:00 AM5/12/99
to
There may be a reason for not doing it, but this works:

proc foo { bam } {
array set ::bar {bim $bam}
}

causes the global array element bar(bim) to be set.
It can now be read anywhere as ::bar(bim) without explicitly
decalring it global.
this is an ab/use of the Tcl namespace feature.

Amusingly, things like $::var and ::$var are equivalent.

I don't think there are arrays in Tcl anyway, otherwise
foo(1,2) and foo(1, 2) would reference the same element!

Bryan Kelly <kel...@brevard.net> wrote:
>> global ip_address
>
>>>This is the way to do it to declare a whole array as global.
>
>The problem I see is that when I do this, then I return back into the mail
>program with
>send_user "\n value is $ip_address(1) "

>It tells that this doesn't exist. With this response, I conclude that
>there are no arrays.
>
>To recap, declare an array, populate it in a procedure, then show the
>contents back in the main function.


--
Phil Ehrens <peh...@ligo.caltech.edu>| Fun stuff:
The LIGO Laboratory, MS 18-34 | http://www.ralphmag.org
California Institute of Technology | http://www.yellow5.com
1200 East California Blvd. | ftp://ftp.no.pgpi.com/pub/pgp
Pasadena, CA 91125 USA | http://slashdot.org
Phone:(626)395-8518 Fax:(626)793-9744 | http://freshmeat.net

Bryan Kelly

unread,
May 12, 1999, 3:00:00 AM5/12/99
to
RE: Umm, technically, that's what arrays are in any language. Most languages

restrict the "index" part of the name to be an integer. Tcl doesn't.

To me, an array is a single entity with a single name that is divided up
into sections for multiple entries of data.
When I ran my program, I kept getting messages saying that the variable did
not exist. I must have had a defect
that wasn't detected by tcl. I will try your code (several versions that I
received) and see how it works so I can
use it.

Donal K. Fellows

unread,
May 13, 1999, 3:00:00 AM5/13/99
to
In article <7hcfor$a...@gap.cco.caltech.edu>,

Phil <peh...@ligo.caltech.edu> wrote:
> proc foo { bam } {
> array set ::bar {bim $bam}
> }

You really meant:
proc foo {bam} {array set ::bar [list bim $bam]}
I forgive you though... :^)

> Amusingly, things like $::var and ::$var are equivalent.

WRONG! They are most definitely not equivalent:

% proc foo {bar} {puts "$::bar - ::$bar"}
% set bar 1; foo 0
1 - ::0

(You had me worried for a few clock ticks there...)

> I don't think there are arrays in Tcl anyway, otherwise
> foo(1,2) and foo(1, 2) would reference the same element!

Tcl does have arrays, but they are not arrays that are indexed by
numbers. Instead, they are indexed by _strings_ (very similar to
arrays in AWK and hashes in Perl) and are great ways to implement
general mappings. The nearest things to C/FORTRAN arrays in Tcl are
probably lists, which (in Tcl8) provide constant-time access to any of
their elements, though value update requires trickery[*] to get
working efficiently.

Donal.
[* Sort-of documented (with a teeny bit of imagination on your part)
in the Wiki <URL:http://purl.org/thecliff/tcl/wiki/TclPerformance> ]
--
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 13, 1999, 3:00:00 AM5/13/99
to
Phil wrote:
> foo(1,2) and foo(1, 2) would reference the same element!

No, those are two different elements of the foo array: one has the index "1,2",
and one has the index "1, 2". You've hit on the usual means to implement
"multi-dimensional" arrays: the convention of separating the index for each
"dimension" with a comma.

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

Phil

unread,
May 13, 1999, 3:00:00 AM5/13/99
to
Christopher Nelson <ch...@pinebush.com> wrote:
>Phil wrote:
>> foo(1,2) and foo(1, 2) would reference the same element!
>
>No, those are two different elements of the foo array: one has the index "1,2",
>and one has the index "1, 2". You've hit on the usual means to implement
>"multi-dimensional" arrays: the convention of separating the index for each
>"dimension" with a comma.

Oh, well that's cute. What's the idea here? You take part of a
sentence, in "out of context" mode, and then pretend I said the
opposite of what I did say? What a prince.

Phil

unread,
May 13, 1999, 3:00:00 AM5/13/99
to
Donal K. Fellows <fell...@cs.man.ac.uk> wrote:
>In article <7hcfor$a...@gap.cco.caltech.edu>,
>Phil <peh...@ligo.caltech.edu> wrote:
>> proc foo { bam } {
>> array set ::bar {bim $bam}
>> }
>
>You really meant:
> proc foo {bam} {array set ::bar [list bim $bam]}
>I forgive you though... :^)

Okay, my generality was suffering a lapse, I concede!

>> Amusingly, things like $::var and ::$var are equivalent.
>
>WRONG! They are most definitely not equivalent:
>
> % proc foo {bar} {puts "$::bar - ::$bar"}
> % set bar 1; foo 0
> 1 - ::0

What about:

set foo 12
set ::$foo twelve
set $foo --> twelve
set $::foo TWELVE
set $foo --> TWELVE

Now it's even more disturbing, dont you think? The local
variable "bar" in proc "foo" is not in the "" namespace
in proc "foo". Where is it?

Phil

Gerald W. Lester

unread,
May 14, 1999, 3:00:00 AM5/14/99
to
Phil wrote:
Donal K. Fellows <fell...@cs.man.ac.uk> wrote:
>In article <7hcfor$a...@gap.cco.caltech.edu>,
>Phil <peh...@ligo.caltech.edu> wrote:
>> proc foo { bam } {
>>      array set ::bar {bim $bam}
>> }
>
>You really meant:
>    proc foo {bam} {array set ::bar [list bim $bam]}
>I forgive you though...  :^)

Okay, my generality was suffering a lapse, I concede!

>> Amusingly, things like $::var and ::$var are equivalent.
>
>WRONG!  They are most definitely not equivalent:
>
>    % proc foo {bar} {puts "$::bar - ::$bar"}
>    % set bar 1; foo 0
>    1 - ::0

What about:

set foo 12
set ::$foo twelve
set $foo --> twelve
set $::foo TWELVE
set $foo --> TWELVE

Now it's even more disturbing, dont you think?

Not at all! The only thing disturbing is you forgetting *where* substitutions happen at, i.e. in the parser.  Lets look at what the set command (at the C level, sees for its arguments) in each case:

set foo 12

Arg #1) foo
Arg #2) 12

Variable foo <= 12

set ::$foo twelve
Arg #1) ::12    (foo has already been substituted!)
Arg #2) twelve

Variable 12 <= twelve

set $foo --> twelve
Arg #1) 12 (foo has already been substituted!)

Returns the value of variable 12, i.e. twelve

set $::foo TWELVE
Arg #1) 12    (::foo, which is the same as foo, has already been substituted!)
Arg #2) TWELVE

Variable 12 <= TWELVE
 

set $foo --> TWELVE
Arg #1) 12 (foo has already been substituted!)

Returns the value of variable 12, i.e. TWELVE

Tcl is very consistent, you just have to remember that it is interpretive and the parser does the substitutions.

 

The local variable "bar" in proc "foo" is not in the "" namespace
in proc "foo".  Where is it?


Here you appear be getting namespaces and scope (i.e. stack frames) confused. They are two completely different things.

--
+--------------------------------+---------------------------------------+
| Gerald W. Lester               | "The man who fights for his ideals is |
| gerald...@bellsouth.net    |  the man who is alive." -- Cervantes  |
|               Webmaster for http://www.mtolive-lcms.org                |
+--------------------------------+---------------------------------------+
 

Phil

unread,
May 14, 1999, 3:00:00 AM5/14/99
to
Gerald W. Lester <Gerald...@cpu.com> wrote:
>
>Here you appear be getting namespaces and scope (i.e. stack frames)
>confused. They are two completely different things.

Ah, well, now I have some embarassing cleaning up to do in
a couple of programs. Thanks for your help.

Robert Heller

unread,
May 16, 1999, 3:00:00 AM5/16/99
to
"Bryan Kelly" <kel...@brevard.net>,
In a message on Mon, 10 May 1999 18:30:09 -0400, wrote :

"K> Are there really arrays in tcl. I don't think there are. Does any one have
"K> an explanation?

What Tcl calls "arrays" SNOBOL calls "tables" and LISP calls association
or property lists. They are implemented with hashtables. Tcl does not
really have what C or FORTRAN or Pascal would call arrays, that is a
slab of same-sized objects that can be numerically indexed.


"K>
"K> Elaboration:
"K> I am using tcl through expect. In trying to work with arrays, I have come
"K> to the conclusion that arrays are not really arrays. they are really a
"K> collection of similiar named variables. I was trying to declare an array
"K> globaly, and it just didn't work. I tired to use an array with the
"K> "fornext" consctuct, but that doesn't work. (I concluded that fornext is for
"K> lists only)
"K>
"K> I find that the book "Exploring Expect" may be okay for non programmers, but
"K> it leaves out one heck of a lot that causes programmers to leap to inproper
"K> conclusions and get scrwed up.
"K>
"K> Here is a short script that I used in messing around with this problem.
"K> This is about the 40th generation, but you should get the idea of what I was
"K> trying to do.
"K>
"K> Thanks for your time,
"K> Bryan
"K>
"K>
"K> ## An array test
"K>
"K>
"K> proc populate_array { }
"K>
The next two lines should not be declared.
"K> global ip_address(0)
"K> global ip_address(1)
Only this line.
"K> global ip_address
"K>
"K> set ip_address(0) "163.206.64.185"
"K> set ip_address(1) "163.206.64.186"
"K>
"K> }
"K> set ip_address(0) "junk"
"K> send_user "\n calling proc next "
"K>
"K> populate_array
"K>
"K> send_user "\n item is $ip_address(0) "

What you really should be doing for the following is this:

global ip_address
foreach i [lsort -integer [array names ip_address]] {
send_user "\n check item $i next "
send_user "\n item $i is $ip_address($i) "
}

"K> for { set i 0 } { $i <= 1 } { incr i } {
"K> send_user "\n check item $i next "
"K> send_user "\n item $i is $ip_address($i) "
"K> }
"K>
"K>
"K>
"K>



--
\/
Robert Heller ||InterNet: hel...@cs.umass.edu
http://vis-www.cs.umass.edu/~heller || hel...@deepsoft.com
http://www.deepsoft.com /\FidoNet: 1:321/153

Bryan Kelly

unread,
May 16, 1999, 3:00:00 AM5/16/99
to
To All,
I do have this section of my program working and want to thank each of you
for your help.

I have a history of programming that extends back even to machine language,
I like assembly language, and most recently have done a fair amount of C
work. In environment, reliability was far more important that speed (lines
of code or execution speed). I have developed a number of attitudes and
concepts to support this environment.

I find that tcl violates many many of these hard earned concepts.
Misspelled variables can be extremely difficult to detect in large sections
of code written by someone else. Sub functions have absolutely no business
declaring a global variable for its parent. Why the heck can't I put that
brace on the next crummy line without a continuation character. And
finally, I continue to cling to my conclusion that there are no arrays in
tcl. If there were, then array( 1,2 ) would index the same element as
array(1,2). FORTRAN has shown very well that the use of blank spaces like
this is NOT a good idea.

However, please don't forget the appreciation I have for the help I received
here,
Bryan

Donal K. Fellows

unread,
May 17, 1999, 3:00:00 AM5/17/99
to
[ OK, I'm pulling your message apart. I think it is easier to read
that way, rather than keeping all the various comments to the end of
the paragraph and requiring everyone to puzzle over just what
sentence matches up to what. ]

In article <3sJ%2.3747$G3.1...@news14.ispnews.com>,


Bryan Kelly <kel...@brevard.net> wrote:
> I find that tcl violates many many of these hard earned concepts.

Computers are more flexible than you (and many others) believe.

> Misspelled variables can be extremely difficult to detect in large
> sections of code written by someone else.

True. It's a tough enough job with a declare-everything-first
language...

> Sub functions have absolutely no business declaring a global
> variable for its parent.

I suspect this is a philosophical point. You won't like Lisp either.

> Why the heck can't I put that
> brace on the next crummy line without a continuation character.

Because Tcl *strongly* encourages you to do it The Right Way using
OTB! :^)

> And
> finally, I continue to cling to my conclusion that there are no arrays in
> tcl. If there were, then array( 1,2 ) would index the same element as
> array(1,2). FORTRAN has shown very well that the use of blank spaces like
> this is NOT a good idea.

You are obviously under the misconception that arrays have to have
numeric-list indices in Tcl. This is not the case. Arrays are a
*general* string -> string mapping mechanism. [set foo(bar) spong] is
perfectly legal. Having leading and trailing spaces be significant in
array indices are just a consequence of that larger reality.

Of course, if you are *defining* arrays as only ever being int list ->
string mappings (as they are in FORTRAN or C) then you are absolutely
right; Tcl does not have arrays. In our opinion, it doesn't need them
crucially either. (You can get a fair bit if the effect of arrays
with lists in Tcl8. Things only get awkward when you want more than
one dimension, and that turns out to be relatively rare in practise.)

> However, please don't forget the appreciation I have for the help I received
> here,

It is very nice to be appreciated, isn't it everyone?

Donal.

Bryan Oakley

unread,
May 17, 1999, 3:00:00 AM5/17/99
to
Bryan Kelly <kel...@brevard.net> wrote in message
news:3sJ%2.3747$G3.1...@news14.ispnews.com...

> To All,
> I do have this section of my program working and want to thank each of you
> for your help.
>
> I have a history of programming that extends back even to machine
language,
> I like assembly language, and most recently have done a fair amount of C
> work. In environment, reliability was far more important that speed
(lines
> of code or execution speed). I have developed a number of attitudes and
> concepts to support this environment.
>
> I find that tcl violates many many of these hard earned concepts.
> Misspelled variables can be extremely difficult to detect in large
sections
> of code written by someone else. Sub functions have absolutely no
business
> declaring a global variable for its parent. Why the heck can't I put that
> brace on the next crummy line without a continuation character. And

> finally, I continue to cling to my conclusion that there are no arrays in
> tcl. If there were, then array( 1,2 ) would index the same element as
> array(1,2). FORTRAN has shown very well that the use of blank spaces like
> this is NOT a good idea.

You are splitting a lot of hairs here. When you say tcl doesn't have arrays,
what you are really saying is that tcl doesn't have numerically indexed
arrays. That much is true. What tcl has is far more flexible than the static
must-use-a-number-for-an-index arrays that more traditional languages have.
Using strings as indicies is much more powerful, IMO. I've used tcl arrays
for close to five years and never once been bothered by the fact they aren't
"real" arrays. To the contrary, I feel liberated. But then, before using tcl
I was a FORTRAN programmer, and was due for some liberation :-)

As for the curly brace issue -- it's merely how the language was formed.
Arguing that you can't put a brace where you want it in tcl is about as
valid as complaining that you can't use curly braces in FORTRAN. Tcl is most
definitely *NOT* C and doesn't even pretend to be.

I'll agree that misspelled variables can be a problem. In theory, anyway.
I've personally never experieced much grief over this one, but maybe I'm
just lucky. I know I've had to track down misspelled variables now and then,
but I've had to do it on other languages too. It's just part of the game.

It sounds to me like Tcl just isn't the language for you. It's certainly not
for everyone, and not for every problem domain. But just because it doesn't
use the same idiom for arrays that some other language(s) do doesn't mean
tcl is inferior in any way. Just different.

Bryan Kelly

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

[ OK, I'm pulling your message apart. I think it is easier to read
that way, rather than keeping all the various comments to the end of
the paragraph and requiring everyone to puzzle over just what
sentence matches up to what. ]

>> Computers are more flexible than you (and many others) believe.

Yes indeed they are. In many senses, that is one of the things that make
programming so difficult. The computer can do anything you can ask of it,
weather or not you really want it to. Problems with computers are almost
never problems with computers. They are almost always problems with the
people. Specifically, the designers and implementers. I make lots and lots
of mistakes and I really like it when the computer can tell me were I
screwed up. Then I can fix it an try, try again until I get it right. But
I need, really need, the computer's help in finding my defects. I want my
tools to help find my errors, not help to hide them.

>> Sub functions have absolutely no business declaring a global
>> variable for its parent.

> I suspect this is a philosophical point. You won't like Lisp either.

No, I don't. I did get an intro to it in college. LISP = Lots of Idiotic
Stupid Parenthesis.

>> Why the heck can't I put that
>> brace on the next crummy line without a continuation character.

>Because Tcl *strongly* encourages you to do it The Right Way using
>OTB! :^)

I don't know what OTB is, but again, that is probably opinion and
philosophical.

> And
> finally, I continue to cling to my conclusion that there are no arrays in
> tcl. If there were, then array( 1,2 ) would index the same element as
> array(1,2). FORTRAN has shown very well that the use of blank spaces like
> this is NOT a good idea.

>> You are obviously under the misconception that arrays have to have


>> numeric-list indices in Tcl. This is not the case. Arrays are a
>> *general* string -> string mapping mechanism. [set foo(bar) spong] is
>> perfectly legal. Having leading and trailing spaces be significant in
>> array indices are just a consequence of that larger reality.

Again, I suppose it is philosophical and in part (or maybe in majority), but
yes, I like my arrays
to be numeric-list indices. I can see a lot of advantages of having
different types
of entities like the things that tcl calls arrays. You can do a lot of
things with them.
But I personally don't like to call them arrays. Only problem is, I don't
know what
else to call them.

Bryan


Bryan Kelly

unread,
May 17, 1999, 3:00:00 AM5/17/99
to
>> Tcl is most definitely *NOT* C and doesn't even pretend to be.

Tell me about:
if { a == b } { do_something} ## The double == requirement. In
how many languages? <g>
for { a = 0} { a < b} { incr a } { do_something } ## Basic format is
right out of C.
set a $b; set c $b; ## note the semicolon for end of statement
character.

Yess indeedie, tcl inherits a lot from the C language. Not, its not a
subset or superset of C,
but it is enough the frustrate C programmers.

Bryan


lvi...@cas.org

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

According to Phil <peh...@ligo.caltech.edu>:
:lvi...@cas.org <lvi...@cas.org> wrote:
:>Would it be possible for someone to implement a 'numerically indexed,
:>traditional array' data type in Tcl, for just such occasions as

:I hope someone at Scriptics has nticed how often this suggestion
:appears in the newsgroup. And how much attention it gets each time.

Actually, I don't recall ever seeing the request before Bryan, myself.

My curiousity is more towards how simple or hard it would be to add to the
Tcl scripting API the ability to create new data types.

From the beginning, John has talked about how simple it was to add flow
control structures, new 'commands' via proc, etc.

I seem to recall at least one or more new data types were added in TclX
(keyed lists, etc.) and perhaps some other of the very early extensions.
But these new datatypes were generally done using the C API.

lvi...@cas.org

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

:Bryan Kelly wrote:
:> Yes indeed they are. In many senses, that is one of the things that make

:> programming so difficult. The computer can do anything you can ask of it,

I'll tell you one thing. I find debugging Tk applications insanely hard
work. Trying to figure out where resources are coming from, what bindings
are firing and what they are doing, why a window on my machine looks different
than on someone else's machine, etc. Now, add in the new Tcl 8.1 headaches of
Unicode, Threading, etc. and whoa - what a pain.

Debuggers, hand editing in puts commands, etc. seldom seem to provide me the
tools sufficient to quickly identify what the problem is. I wonder if
anyone will ever write a 'Efficient debugging of Tcl/Tk applications'
book...

Phil

unread,
May 18, 1999, 3:00:00 AM5/18/99
to
lvi...@cas.org <lvi...@cas.org> wrote:
>
>According to Phil <peh...@ligo.caltech.edu>:
>:lvi...@cas.org <lvi...@cas.org> wrote:
>:>Would it be possible for someone to implement a 'numerically indexed,
>:>traditional array' data type in Tcl, for just such occasions as
>
>:I hope someone at Scriptics has nticed how often this suggestion
>:appears in the newsgroup. And how much attention it gets each time.
>
>Actually, I don't recall ever seeing the request before Bryan, myself.

Well, of course, the reason I mentioned it is because I
requested it about 6 months ago. I realise that I'm not
one of "The Lords of Tcl"... but the thread went almost
exactly the same as this one. I think even Dr.O himself
commented.

Phil

Michael L. Siemon

unread,
May 18, 1999, 3:00:00 AM5/18/99
to
In article <7hsr1h$g...@gap.cco.caltech.edu>, peh...@ligo.caltech.edu wrote:

+ >Actually, I don't recall ever seeing the request before Bryan, myself.
+
+ Well, of course, the reason I mentioned it is because I
+ requested it about 6 months ago.

I'm afraid I don't understand _why_ you (or others) want a
FORTRAN-like array. It's not as if TCL were compiling your
expressions into multiple simultaneous traversal of some
homogeneous vector(s) of data being ground together by a
DSP or such-like. At the level of TCL programming, hash
access to arbitrary indexes is at least as good as the
traditional index arithmetic that becomes more and more
expensive with each dimension added.

If you are dealing with machine-generated indexes, there
is no possibility of confusions with extra spaces to make
the array elements ambiguous. If you are dealing with human
inputs, it is trivial to strip spaces [and maybe leading zeros]
before doing array accesses. At that point you can _pretend_
(though I don't advise tying your head into such silly knots)
that you have "classic" multidimensional arrays. Unless you
are implementing algorithms that _depend_ on "linear"
access to elements along one dimensional slice of such a
classic array (and then, you've got the issue that traditional
languages don't agree on the order in which they slice these!)
I can't see any point to it.

A TCL hash-table == "associative array" is a perfectly adequate
vehicle for defining integer-indexed arrays of same-type
objects. It also has a _lot_ of vastly more interesting uses!
--
Michael L. Siemon We must know the truth, and we must
m...@panix.com love the truth we know, and we must
act according to the measure of our love.
-- Thomas Merton

Bryan Oakley

unread,
May 18, 1999, 3:00:00 AM5/18/99
to
<lvi...@cas.org> wrote in message news:7hsomi$i80$1...@srv38s4u.cas.org...

>
> :Bryan Kelly wrote:
> :> Yes indeed they are. In many senses, that is one of the things that
make
> :> programming so difficult. The computer can do anything you can ask of
it,
>
> I'll tell you one thing. I find debugging Tk applications insanely hard
> work.

Really? Wow. That's interesting. I've found just the opposite. Mainly I've
found tk scripts to be insanely easy to debug, relative to some other window
system.

> Trying to figure out where resources are coming from,

... with a few exceptions. This one has always bugged me, to the point where
I try to avoid using resources. They are powerful, but difficult to fathom.

> what bindings
> are firing and what they are doing, why a window on my machine looks
different
> than on someone else's machine, etc. Now, add in the new Tcl 8.1
headaches of
> Unicode, Threading, etc. and whoa - what a pain.

I can't speak yet to dealing with unicode and treading, but I've not had
much problem with the other areas you speak of. That's not to say they
don't exist; just that my experience is different.

>
> Debuggers, hand editing in puts commands, etc. seldom seem to provide me
the
> tools sufficient to quickly identify what the problem is. I wonder if
> anyone will ever write a 'Efficient debugging of Tcl/Tk applications'
> book...

I used to be a FORTRAN programmer, where print statements were all I had for
several years. Well, yeah, the Data General system had a debugger (swat --
what a great name) but it was pretty lousy. It was easier to just put in
print statements. Once you do that a few million times it gets easier.

And of course, now we have the tcl pro debugger. And tuba (is that it?). So
things are definitely improving.

I'll still take tcl and tk over C and Motif any day of the week, and the
weekends too.


Bryan Kelly

unread,
May 18, 1999, 3:00:00 AM5/18/99
to
<big snip>
> And, of course, actually setting a value in a list that is a subset of a
> list is difficult.

That is why you need Feather with its mutable vector which allows you
to do the following.
< ending snip>

Now we seem to have found a need all kinds of tools to emulate something as
simple as
a = b( c, d )
who's functionality is (or should be to my mind) exactly identical to
a = b ( c , d )
and any other permutation.

tcl does some things better than anything else I know of, but handling
arrays isn't one of them.
I will mightily endeavor to avoid arrays as much as I can in tcl. And where
I can't, I will strive
for the simplest possible implementation.

Bryan

Bryan Kelly

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

>>I'll stand by my statement that tcl doesn't even pretend to be C. Sure, it
borrows some of the constructs, but it also borrows a bit from other
languages. That much is unavoidable.

I agree with you there. Without going back and checking it, my intent
wasn't to say that is pretends to be C, but that the similarities to C have
been causing me some problems. If my recent history had been something
else, I probably would have complained about those similarities.

I have become accustomed to the relatively free formatting of C and find it
irritating as all-get-out when I can't omit or add a white space around a
brace or bracket. My eyes are going down hill and I have grown accustomed
to using white space to separate parts and make it easier for me to read on
a crowded screen.


>> Funny thing, this similarity to other languages -- ages ago (15 years?) I
used to think doing "let foo = bar" (or whatever the BASIC syntax of the day
was) was stupid. Why require the keyword "let"? But when I started doing tcl
close to five years ago, "set" seemed so natural that I never questioned it.
I'm not trying to make a point with that -- just an interesting observation.

Your right. I feel its kind of silly, but it is clear and simple enough
that it didn't cause me a problem, so I didn't think about it.

I did think about the use of the dollar sign.

set a $b

Why do I need it for the "b" and not for the "a". If you really think about
it, both of them are using a label to represent a value that is being copied
from one place to another. I sort of see the $ in tcl as acting like the *
in C. (Don't flame me over that, I do know the difference, I am also just
making an observation.) From the perspective of a C or Pascal, or FORTRAN,
or assembly language, that use is inconsistent.

Bryan

Bryan Kelly

unread,
May 18, 1999, 3:00:00 AM5/18/99
to
>> Good luck finding a scripting language that is fast, flexible, enforces
the strictness you want, but lets you code in your personal style. It's
a grail that programmers sometimes spend significant portions of their
lives seeking.


I don't think the beast exists. tcl and expect have what I perceive to be a
fairly clear target. To automate things normally done by hand. (Not a
limiting statement, there are others, but being new with tcl / expect, I see
this one first.) In the book Exploring Expect, there are some examples
that show how good it can be. Indeed, in my world, I will use expect to
telnet to 12 machines simultaneously, issue commands on one machine, and
verify that the command is properly propagated throughout the system. I
don't think there is anything else that will do the job as well as expect /
tcl.

However, I don't think that tcl is intended to do some of the things that C
and FORTRAN do so well. Dealing with arrays is one of them. I suspect that
dealing with complex conditions and things that need abstraction isn't for
expect / tcl.

Any language that is stretched past its limits becomes unmanageable. And
every language that will ever be devised will have limits.

Bryan


Volker Hetzer

unread,
May 18, 1999, 3:00:00 AM5/18/99
to
Bryan Kelly wrote:
> [someone else that got deleted, but not by me :-)]

> >> Sub functions have absolutely no business declaring a global
> >> variable for its parent.
Why not?
A couple of days ago I did a nice little function to process options
in procedure calls. You give it the option (as regex) the call-type
(bool, value, reference) and the variable you want the value bound to.
The function then creates all the variables with the right values (or
bound to the right uplevel variables). Then you can simply check with
[info exist ...] whether all the options heve been given.


> No, I don't. I did get an intro to it in college. LISP = Lots of Idiotic
> Stupid Parenthesis.

If the brackets are the only things you don't like in LISP, consider
Tcl as a lisp without 80% of the brackets.

> >> Why the heck can't I put that
> >> brace on the next crummy line without a continuation character.

Because that would break a lot of other things I won't want to miss.
Suddenly you would have a distinction between functions that are special
(like for, while or proc) and functions that aren't. That would
mean I could not do my own control structures or blocks.
This would be very bad as I use Tcl to provide customised languages to
my users.

> >Because Tcl *strongly* encourages you to do it The Right Way using
> >OTB! :^)
>
> I don't know what OTB is, but again, that is probably opinion and
> philosophical.

It is. What about getting a decent editor that recognices the commands
you find special and inserts the continuation automatically?

> > And
> > finally, I continue to cling to my conclusion that there are no arrays in
> > tcl. If there were, then array( 1,2 ) would index the same element as
> > array(1,2).

Your definition of "array" is too narrow.
Look up the Tcl-manual what a array in Tcl is.

> Again, I suppose it is philosophical and in part (or maybe in majority), but
> yes, I like my arrays to be numeric-list indices. I can see a lot of advantages of having
> different types of entities like the things that tcl calls arrays. You can do a lot of
> things with them. But I personally don't like to call them arrays. Only problem is, I don't
> know what else to call them.

Just another reason to call them by their rightful name.

Volker

lvi...@cas.org

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

According to Bryan Kelly <kel...@brevard.net>:
:work. In environment, reliability was far more important that speed (lines

:of code or execution speed). I have developed a number of attitudes and
:concepts to support this environment.
:
:I find that tcl violates many many of these hard earned concepts.

It sounds to me like you were / are expecting Tcl to act as some other
language. Unfortunately, I am uncertain which other language to recommend.
For scripting languages who care less about white space than Tcl, I guess I
would recommend Perl. However, for languages which enforce variable
naming and tighter scoping, I would probably recommend Python, which
unfortunately requires a particular physical code layout style, but
might be able to do the rest of what you want.

Good luck finding a scripting language that is fast, flexible, enforces
the strictness you want, but lets you code in your personal style. It's
a grail that programmers sometimes spend significant portions of their
lives seeking.

--

lvi...@cas.org

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

According to Volker Hetzer <volker...@abg1.siemens.de>:
:(like for, while or proc) and functions that aren't. That would

:mean I could not do my own control structures or blocks.

Would it be possible for someone to implement a 'numerically indexed,


traditional array' data type in Tcl, for just such occasions as

Bryan wishes? Of course, this doesn't help his other concerns...

Are there any options for some of the other items of dissonance that
Bryan mentioned earlier in this thread?

Alexandre Ferrieux

unread,
May 18, 1999, 3:00:00 AM5/18/99
to
lvi...@cas.org wrote:
>
> According to Volker Hetzer <volker...@abg1.siemens.de>:
> :(like for, while or proc) and functions that aren't. That would
> :mean I could not do my own control structures or blocks.
>
> Would it be possible for someone to implement a 'numerically indexed,
> traditional array' data type in Tcl, for just such occasions as
> Bryan wishes?

What's wrong with simple lists ? (O(1) access).
What's wrong with BLT's or Feather's (and maybe a couple of others)
vectors ?

-Alex

Paul Duffin

unread,
May 18, 1999, 3:00:00 AM5/18/99
to Bryan Kelly
Bryan Kelly wrote:
>
> [ OK, I'm pulling your message apart. I think it is easier to read
> that way, rather than keeping all the various comments to the end of
> the paragraph and requiring everyone to puzzle over just what
> sentence matches up to what. ]
>
> >> Computers are more flexible than you (and many others) believe.
>
> Yes indeed they are. In many senses, that is one of the things that make
> programming so difficult. The computer can do anything you can ask of it,
> weather or not you really want it to. Problems with computers are almost
> never problems with computers. They are almost always problems with the
> people. Specifically, the designers and implementers. I make lots and lots
> of mistakes and I really like it when the computer can tell me were I
> screwed up. Then I can fix it an try, try again until I get it right. But
> I need, really need, the computer's help in finding my defects. I want my
> tools to help find my errors, not help to hide them.
>
> >> Sub functions have absolutely no business declaring a global
> >> variable for its parent.
>
> > I suspect this is a philosophical point. You won't like Lisp either.
>
> No, I don't. I did get an intro to it in college. LISP = Lots of Idiotic
> Stupid Parenthesis.
>
> >> Why the heck can't I put that
> >> brace on the next crummy line without a continuation character.
>
> >Because Tcl *strongly* encourages you to do it The Right Way using
> >OTB! :^)
>
> I don't know what OTB is, but again, that is probably opinion and
> philosophical.
>
> > And
> > finally, I continue to cling to my conclusion that there are no arrays in
> > tcl. If there were, then array( 1,2 ) would index the same element as
> > array(1,2). FORTRAN has shown very well that the use of blank spaces like
> > this is NOT a good idea.
>
> >> You are obviously under the misconception that arrays have to have
> >> numeric-list indices in Tcl. This is not the case. Arrays are a
> >> *general* string -> string mapping mechanism. [set foo(bar) spong] is
> >> perfectly legal. Having leading and trailing spaces be significant in
> >> array indices are just a consequence of that larger reality.
>
> Again, I suppose it is philosophical and in part (or maybe in majority), but
> yes, I like my arrays
> to be numeric-list indices. I can see a lot of advantages of having
> different types
> of entities like the things that tcl calls arrays. You can do a lot of
> things with them.
> But I personally don't like to call them arrays. Only problem is, I don't
> know what
> else to call them.
>

How about vectors ?
Why don't you take a look at Feather (some blurb at)
http://216.71.55.6/cgi-bin/wikit/402.html
it contains various new mutable data types plus lots of other goodies
which you may find useful (including lambda and curryied objects).

You can use the vector like this.

% set a [vector create 1 2 3 4]
<feather::vector 0x200201d8>
% getx $a 0
1
% setx $a 0 9
% vector contents $a
9 2 3 4

Feather is not ready yet but the more people who are interested the
quicker it will be.

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

Hume Smith

unread,
May 18, 1999, 3:00:00 AM5/18/99
to
"Bryan Kelly" <kel...@brevard.net> wrote:

>>> Why the heck can't I put that
>>> brace on the next crummy line without a continuation character.

because newline can stand in place of semicolon; so you don't need lots of
stupid semicolons all over. saying
if 1
{ puts hi }
in TCL is (almost) like
if (1);
{ printf("hi\n"); }
in C. (The C actually works, though...)

>> And
>> finally, I continue to cling to my conclusion that there are no arrays in
>> tcl.

they aren't arrays as vectors. they're what i learned were called associative
arrays, and they're implemented as hashtables. take your pick. they're
wonderful for the kind of things for which Tcl is designed; they're not so
hot for the Fortran crowd.


Bryan Oakley

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

Bryan Kelly <kel...@brevard.net> wrote in message
news:QJ303.8929$LP2.1...@news6.ispnews.com...

> >> Tcl is most definitely *NOT* C and doesn't even pretend to be.
>
> Tell me about:
> if { a == b } { do_something} ## The double == requirement. In
> how many languages? <g>
> for { a = 0} { a < b} { incr a } { do_something } ## Basic format is
> right out of C.
> set a $b; set c $b; ## note the semicolon for end of statement
> character.
>
> Yess indeedie, tcl inherits a lot from the C language.

Not a lot. *Some*. I'd venture to say it is impossible to create a new
language that doesn't borrow constructs from other languages. There are only
so many ways to do equality tests, and of those only two or three really
make sense. So, if we didn't borrow from C we would have had to borrow from
some other language. C was the most reasonable in this case since the
software was written in C and was designed to be embedded in C programs.

> Not, its not a
> subset or superset of C,
> but it is enough the frustrate C programmers.

I've personally never witnessed that. Well, ok, I've seen postings from
people who think tcl is C (or C-like) and thus get confused about braces.
But I've seen people get confused writing C when they think it should be
like Basic, and I've seen people get confused when they think Java is like
C. It's unavoidable when people learn their second language.

I'll stand by my statement that tcl doesn't even pretend to be C. Sure, it
borrows some of the constructs, but it also borrows a bit from other

languages. That much is unavoidable. For every feature you can find that
mimics C, I can find two or more features that don't. So I don't see, if tcl
mimics only 1/3 (or, more likely, 1/10th or 1/100th) of the features of C,
how anyone can say it pretends to be C.

Phil

unread,
May 18, 1999, 3:00:00 AM5/18/99
to
lvi...@cas.org <lvi...@cas.org> wrote:
>Would it be possible for someone to implement a 'numerically indexed,
>traditional array' data type in Tcl, for just such occasions as
>Bryan wishes? Of course, this doesn't help his other concerns...

I hope someone at Scriptics has nticed how often this suggestion


appears in the newsgroup. And how much attention it gets each time.

I am of course being facetious, since I KNOW that Dr. O is aware
of this want of "more traditional, numerically subscripted arrays".

It wouldn't stop being Tcl just because it had a more c-like
array type!

Bryan Oakley

unread,
May 18, 1999, 3:00:00 AM5/18/99
to
Alexandre Ferrieux <alexandre...@cnet.francetelecom.fr> wrote in
message news:374163...@cnet.francetelecom.fr...

> lvi...@cas.org wrote:
> >
> > According to Volker Hetzer <volker...@abg1.siemens.de>:
> > :(like for, while or proc) and functions that aren't. That would
> > :mean I could not do my own control structures or blocks.
> >
> > Would it be possible for someone to implement a 'numerically indexed,
> > traditional array' data type in Tcl, for just such occasions as
> > Bryan wishes?

I'm sure it could be done, and fairly easily. One could just do some index
munging within the existing array code to remove whitespace and give errors
if there is anything but digits and commas in the index. But what's the
point? To _remove_ functionality? I don't like the sound of that. Time
would be better spent to write a tiny program that reads in your source code
and looks for array indicies that have spaces in them, and remove them.
Things like "set foo(10, 20, 30)" would become "set foo(10,20,30)" and so
on.

> What's wrong with simple lists ? (O(1) access).

Because, I'm guessing, they don't share the syntax of traditional arrays and
it seems Bryan wants to keep all the strengths and weaknesses of traditional
arrays. Plus, multidimensional arrays can't be done with lists. Not with a
reasonable syntax anyway. I doubt the following:

set foo [lindex [lindex $baz 0] 2]

... would be considered a reasonable alternative to

set foo $somearray(2,0)

Paul Duffin

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

That is why you need Feather with its mutable vector which allows you
to do the following.

% set a [vector create [vector create 2 9 4] \
[vector create 7 5 3] \
[vector create 6 1 8]]
<feather::vector 0x2001fc58>
% getx $a 0
<feather::vector 0x2001f978>
% getx $a 0 2
4
% vector contents [getx $a 0]
2 9 4
% vector contents [getx $a 1]
7 5 3
% vector contents [getx $a 2]
6 1 8
% setx $a 0 2 99
% setx $a 2 0 -76
% vector contents [getx $a 0]
2 9 99
% vector contents [getx $a 1]
7 5 3
% vector contents [getx $a 2]
-76 1 8

lvi...@cas.org

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

According to Bryan Oakley <oak...@channelpoint.com>:
:I'll still take tcl and tk over C and Motif any day of the week, and the
:weekends too.

I will grant you that. However, Tk is in general a lot tougher than
vanilla C standard filters... I never deal with any other kind of window
apps other than Tk/Tcl, so perhaps it's not Tk specifically but event
driven GUI apps that are tough to debug...

Paul Duffin

unread,
May 19, 1999, 3:00:00 AM5/19/99
to peh...@ligo.caltech.edu
Phil wrote:
>
> lvi...@cas.org <lvi...@cas.org> wrote:
> >
> >According to Phil <peh...@ligo.caltech.edu>:
> >:lvi...@cas.org <lvi...@cas.org> wrote:
> >:>Would it be possible for someone to implement a 'numerically indexed,

> >:>traditional array' data type in Tcl, for just such occasions as
> >
> >:I hope someone at Scriptics has nticed how often this suggestion

> >:appears in the newsgroup. And how much attention it gets each time.
> >
> >Actually, I don't recall ever seeing the request before Bryan, myself.
>
> Well, of course, the reason I mentioned it is because I
> requested it about 6 months ago. I realise that I'm not
> one of "The Lords of Tcl"... but the thread went almost
> exactly the same as this one. I think even Dr.O himself
> commented.
>

Look for "vector" here.
http://216.71.55.6/cgi-bin/wikit/402.html
It is not yet ready for release but it is certainly getting there.

Paul Duffin

unread,
May 19, 1999, 3:00:00 AM5/19/99
to
Bryan Kelly wrote:

>
> Bryan Oayley wrote:
> >>I'll stand by my statement that tcl doesn't even pretend to be C. Sure, it
> > borrows some of the constructs, but it also borrows a bit from other
> > languages. That much is unavoidable.
>
> I agree with you there. Without going back and checking it, my intent
> wasn't to say that is pretends to be C, but that the similarities to C have
> been causing me some problems. If my recent history had been something
> else, I probably would have complained about those similarities.
>
> I have become accustomed to the relatively free formatting of C and find it
> irritating as all-get-out when I can't omit or add a white space around a
> brace or bracket. My eyes are going down hill and I have grown accustomed
> to using white space to separate parts and make it easier for me to read on
> a crowded screen.
>

You can add whitespaces in Tcl code if you want.
e.g.
if { $a + 2 == 99 } {


set a 98

}

> Bryan Oayley wrote:
> >> Funny thing, this similarity to other languages -- ages ago (15 years?) I
> > used to think doing "let foo = bar" (or whatever the BASIC syntax of the day
> > was) was stupid. Why require the keyword "let"? But when I started doing tcl
> > close to five years ago, "set" seemed so natural that I never questioned it.
> > I'm not trying to make a point with that -- just an interesting observation.
>

> Your right. I feel its kind of silly, but it is clear and simple enough
> that it didn't cause me a problem, so I didn't think about it.
>
> I did think about the use of the dollar sign.
>
> set a $b
>
> Why do I need it for the "b" and not for the "a". If you really think about
> it, both of them are using a label to represent a value that is being copied
> from one place to another. I sort of see the $ in tcl as acting like the *
> in C. (Don't flame me over that, I do know the difference, I am also just
> making an observation.) From the perspective of a C or Pascal, or FORTRAN,
> or assembly language, that use is inconsistent.
>

Actually the reason why you need both is that Tcl is extremely consistent.
Ignoring the byte compiler the parsing of a command line is done the same
way for all commands irrespective of whether it is a builtin or a user
defined one. When parsing a set command the parser does not 'know' that
the first parameter after set is a command name (lvalue) and the second is
a value (rvalue), this means that you need a way to distinguish between a
variable name (lvalue) and the value associated with the variable (rvalue).

Changing this behaviour would of course result in a language which was not
Tcl. The byte compiler is written so as not to break this behaviour.

C and Pascal and FORTRAN all use the context to decide whether a name
is referring to an lvalue or an rvalue which means that you cannot
extend their syntax without changing the compiler. Looking at Tcl from
the perspective of many (all ??) languages can be disconcerting as Tcl
is different to most (all ??) of them.

Paul Duffin

unread,
May 19, 1999, 3:00:00 AM5/19/99
to
Bryan Kelly wrote:
>
> >> Good luck finding a scripting language that is fast, flexible, enforces
> the strictness you want, but lets you code in your personal style. It's
> a grail that programmers sometimes spend significant portions of their
> lives seeking.
>
> I don't think the beast exists. tcl and expect have what I perceive to be a
> fairly clear target. To automate things normally done by hand. (Not a
> limiting statement, there are others, but being new with tcl / expect, I see
> this one first.) In the book Exploring Expect, there are some examples
> that show how good it can be. Indeed, in my world, I will use expect to
> telnet to 12 machines simultaneously, issue commands on one machine, and
> verify that the command is properly propagated throughout the system. I
> don't think there is anything else that will do the job as well as expect /
> tcl.
>
> However, I don't think that tcl is intended to do some of the things that C
> and FORTRAN do so well. Dealing with arrays is one of them. I suspect that
> dealing with complex conditions and things that need abstraction isn't for
> expect / tcl.
>

Actually I think you will find an awful lot of people out there have
managed to write very extensive applications in Tcl. Writing in Tcl does
involve different skills to writing in other languages but hopefully you
will stick with it long enough to discover its power and flexibility.

> Any language that is stretched past its limits becomes unmanageable. And
> every language that will ever be devised will have limits.
>

I do not think that Tcl has yet reached its limit, as illustrated by Fe....
Ok, I will stop talking about it (at least on this thread...for now).

Volker Hetzer

unread,
May 19, 1999, 3:00:00 AM5/19/99
to
Bryan Kelly wrote:

> tcl does some things better than anything else I know of, but handling
> arrays isn't one of them.
> I will mightily endeavor to avoid arrays as much as I can in tcl. And where

If you mean tcl-arrays (or whatever you want to call them) as they exist today
I'd use them wherever possible. After all, it IS the most powerful data structure
tcl has today. :-)

Bryan Oakley

unread,
May 19, 1999, 3:00:00 AM5/19/99
to
Bryan Kelly <kel...@brevard.net> wrote in message
news:oco03.10331$LP2.2...@news6.ispnews.com...

> Now we seem to have found a need all kinds of tools to emulate something
as
> simple as
> a = b( c, d )
> who's functionality is (or should be to my mind) exactly identical to
> a = b ( c , d )
> and any other permutation.

For the life of me I can't figure out why those two must be equivalent. If
they must be, simply wrap your indicies in a normalizing function first. It
may not be quite as "pure" as you are looking for, but it seems to meet your
requirements:

proc normalize {args} {
set string [join $args {}]
regsub -all " \t\n" $string {} string
return $string
}

% set foo([normalize 10 , 20]) "row 10, column 20"
row 10, column 20
% puts "item 10,20 is '$foo([normalize 10,20])'"
item 10,20 is 'row10, column 20'

Of course, you can pick something less verbose if you want, for example,
"_":

% puts "item 10,20 is $foo([_10 , 20])"

It adds only three extra characters to any array reference (at the expense
of performace, obviously). Of course, you could also do this for yourself in
C by modifying the tcl source directly, to do effectively the same thing but
much faster.

But I don't see any advantage in that. It seems your main concern is that
tcl should cover for your own typing mistakes (ie: treat " 10 , 20 " the
same as "10,20"). While that is a valid desire, it's not what tcl is about,
and changing it would change the very nature of tcl.

>
> tcl does some things better than anything else I know of, but handling
> arrays isn't one of them.

Judging by the length of this thread, that statement is arguable. My opinion
is that handling arrays is something tcl excels at.

> I will mightily endeavor to avoid arrays as much as I can in tcl. And
where

> I can't, I will strive
> for the simplest possible implementation.

The simplest possible implementation is always the best, in my opinion. But
to limit yourself by eschewing tcl arrays seems pointless. They are an
extremely powerful tool. I don't think I've ever written any tcl code of any
significant size whatsoever without making use of arrays. And the fact that
they aren't "real" arrays but rather associative arrays, does nothing but
make the job easier, IMO.

But, of course, you must do what makes _you_ the most productive. And if
that means you use something other than arrays, so much the better. The
ultimate goal for anyone who uses tcl should be simply to Get The Job Done.

Tcl is a wonderful language but, like any language, it isn't for everyone.

>
> Bryan
>

Bryan! (I almost feel like I'm talking to myself :-)

Bryan Oakley

unread,
May 19, 1999, 3:00:00 AM5/19/99
to
Bryan Kelly <kel...@brevard.net> wrote in message
news:pco03.10332$LP2.2...@news6.ispnews.com...

> I did think about the use of the dollar sign.
>
> set a $b
>
> Why do I need it for the "b" and not for the "a". If you really think
about
> it, both of them are using a label to represent a value that is being
copied
> from one place to another.

Actually, that is an incorrect assesment. a and $b are merely arguments to a
command that happens to copy data to a variable name. Remember that from a
philosophical point of view, the tcl interpreter has no idea that the set
command assigns data to a variable. All it knows is that it must send the
set command two pieces of data. What the set command does with that is
entirely up to the set command.

> I sort of see the $ in tcl as acting like the *
> in C. (Don't flame me over that, I do know the difference, I am also just
> making an observation.)

That is a fairly correct observation. All the dollar sign means is "return
the value of the variable who's name follows the dollar sign".

> From the perspective of a C or Pascal, or FORTRAN,
> or assembly language, that use is inconsistent.

Yes it is. But from the perspective of tcl, it is perfectly consistent. And
that's the point, eh? To be internally consistent, rather than to mimic
other languages. It's what I like most about tcl -- it's utter simplicity
and predictability. But I can see how it will seem to behave erratically if
you expect it to behave like more traditional languages. Much the same can
be said for any scripting language. Perl certainly doesn't behave like C.
Ditto lisp.


Bryan Oakley

unread,
May 19, 1999, 3:00:00 AM5/19/99
to
<lvi...@cas.org> wrote in message news:7ht5vn$p6d$1...@srv38s4u.cas.org...

>
> According to Bryan Oakley <oak...@channelpoint.com>:
> :I'll still take tcl and tk over C and Motif any day of the week, and the
> :weekends too.
>
> I will grant you that. However, Tk is in general a lot tougher than
> vanilla C standard filters... I never deal with any other kind of window
> apps other than Tk/Tcl, so perhaps it's not Tk specifically but event
> driven GUI apps that are tough to debug...

Debugging event driven apps certainly requires different techniques than
something like a simple C filter program. I guess I've been doing it long
enough that I can't remember what it was like when first working with event
driven programs. It was probably painful, and I've subconsciously blocked
that pain :-)


Bryan Kelly

unread,
May 19, 1999, 3:00:00 AM5/19/99
to
The concept of not being context sensitive appears to be the key. In a
compiled language, there is obviously no problem with being context
sensitive. Personally, since I base everything in terms of past experience
(like everyone), I like the context sensitive approach.

However, Maybe I ought to consider the alternative. It will be a
significant change.

Bryan


Darren New

unread,
May 19, 1999, 3:00:00 AM5/19/99
to
Bryan Kelly wrote:
>
> The concept of not being context sensitive appears to be the key. In a
> compiled language, there is obviously no problem with being context
> sensitive.

It's not a matter of whether Tcl is compiled or not. It's a matter of
whether Tcl is extensible or not.

For my zonk command, given

zonk a $b c

should it take the value of "c", or is it going to modify the variable
named "c", or is "c" a format specifier saying I want a single
character? *That* is why you need the $.

It's like allowing the user to add a @ operator in C, so I can say

if ( (a + 2) @ (c * 3)) { ... }

and then complaining that I need the parens to show the order of
evaluation I want. It's necessary unless you start adding lots of
extraneous syntax for declaring what @ does. It has nothing to do with
whether C is compiled or not. It has to do with whether you can add to
the language afterwards. And *that* is Tcl's amazing strength compared
to anything else I've ever found; the fact that you can add to it
without easily getting burned. (Lisp and Forth both are extensible too,
but I find it way easier to make hard-to-find mistakes in both of those
languages than in Tcl.)

--
Darren New / Senior Software Architect / MessageMedia, Inc.
San Diego, CA, USA (PST). Cryptokeys on demand.
Help outlaw Hydrogen Dioxide, a major component of acid rain!

Donal K. Fellows

unread,
May 20, 1999, 3:00:00 AM5/20/99
to
In article <7ht5vn$p6d$1...@srv38s4u.cas.org>, <lvi...@cas.org> wrote:
> I will grant you that. However, Tk is in general a lot tougher than
> vanilla C standard filters... I never deal with any other kind of
> window apps other than Tk/Tcl, so perhaps it's not Tk specifically
> but event driven GUI apps that are tough to debug...

I think you're right there. Sophisticated stuff is never going to be
all that easy to debug. Event-driven stuff is not all that easy to
reason about either (the Semantics of Reactive Programs is an area
with a lot of research effort being thrown at it at the moment...)

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>

Alexandre Ferrieux

unread,
May 20, 1999, 3:00:00 AM5/20/99
to
Donal K. Fellows wrote:
>
> In article <7ht5vn$p6d$1...@srv38s4u.cas.org>, <lvi...@cas.org> wrote:
> > I will grant you that. However, Tk is in general a lot tougher than
> > vanilla C standard filters... I never deal with any other kind of
> > window apps other than Tk/Tcl, so perhaps it's not Tk specifically
> > but event driven GUI apps that are tough to debug...
>
> I think you're right there. Sophisticated stuff is never going to be
> all that easy to debug. Event-driven stuff is not all that easy to
> reason about either

But still so much easier than thread sync headaches :)

-Alex

Donal K. Fellows

unread,
May 20, 1999, 3:00:00 AM5/20/99
to
In article <pco03.10332$LP2.2...@news6.ispnews.com>,

Bryan Kelly <kel...@brevard.net> wrote:
> I did think about the use of the dollar sign.
> set a $b
>
> Why do I need it for the "b" and not for the "a". If you really
> think about it, both of them are using a label to represent a value
> that is being copied from one place to another. I sort of see the $

> in tcl as acting like the * in C. (Don't flame me over that, I do
> know the difference, I am also just making an observation.)

I *like* that analogy. It's a good one.

> From the perspective of a C or Pascal, or FORTRAN, or assembly
> language, that use is inconsistent.

But that use is right at the heart of what Tcl is and does. There are
some tricks you can pull though:

proc setv {variableWrite variableRead} {
upvar 1 $variableWrite v1 $variableRead v2
set v1 $v2
}
# Now we can do something closer to what you are used to...
setv a b
setv myHomeDir env(HOME)

Note that the way that you can create these new language constructs
(of which the above is just a small sample) is strongly dependant on
another feature of Tcl that you said you didn't like - the ability of
a procedure to manipulate (and possibly create) variables in the
environment which called it. This is a major part of the power of
Tcl, and it is something that simply isn't available in the likes of C
and FORTRAN (without doing something *very* nasty indeed...)

I believe that the languages of the future will have introspective
capabilities (it is very useful in many surprising places.) You may
as well get used to it.

Donal K. Fellows

unread,
May 20, 1999, 3:00:00 AM5/20/99
to
In article <rco03.10333$LP2.2...@news6.ispnews.com>,
Bryan Kelly <kel...@brevard.net> wrote:
[...]

> tcl and expect have what I perceive to be a fairly clear target. To
> automate things normally done by hand. (Not a limiting statement,
> there are others, but being new with tcl / expect, I see this one
> first.)
[...]

You've clearly identified the purpose of expect, but not the role of
Tcl. Tcl's primary role is to provide a common base for a scripting
language that can be extended with (non-Tcl) application-specific
stuff to form a language for controlling a system. It turns out that
this base is actually large enough and sophisticated enough for
complex applications to be written without any additional non-Tcl
code, but that is just a happy side-effect.

Donal K. Fellows

unread,
May 20, 1999, 3:00:00 AM5/20/99
to
In article <PJ303.8928$LP2.1...@news6.ispnews.com>,

Bryan Kelly <kel...@brevard.net> wrote:
>> Because Tcl *strongly* encourages you to do it The Right Way using
>> OTB! :^)
>
> I don't know what OTB is, but again, that is probably opinion and
> philosophical.

One True Brace. It is not philosophical opinion, but rather Revealed
TRVTH. It is also the style that is described in the Tcl Engineering
Guide/Manual and is used consistently throughout the whole of the C
implementation of Tcl and Tk. I find it very easy to read and write.

[...]


> Again, I suppose it is philosophical and in part (or maybe in
> majority), but yes, I like my arrays to be numeric-list indices. I
> can see a lot of advantages of having different types of entities
> like the things that tcl calls arrays. You can do a lot of things
> with them. But I personally don't like to call them arrays. Only
> problem is, I don't know what else to call them.

The general term (which encompasses arrays as you understand them,
hash tables, functions, and a whole load of different kinds of trees)
is a Map. Maps are mechanisms whereby you put a value in and get a
value out. They are *very* general indeed. Selecting the right kind
of map for a particular use requires deep thought on what exactly is
going on and what operations you want it to support with what
efficiency. Extensible perfect hashing (as used by Tcl) is one of the
best solutions for the general string|->something type of map where
the number of elements cannot be fixed by other means and run-time
update of both the domain and the range is required. Standard vectors
have other advantages (much cheaper to create as a whole, and very
cheap indexing since the index is an integer and can be used directly
instead of requiring mapping to an internal form.)

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

unread,
May 20, 1999, 3:00:00 AM5/20/99
to
Donal K. Fellows <fell...@cs.man.ac.uk> wrote:

> Bryan Kelly <kel...@brevard.net> wrote:
>> I don't know what OTB is, but again, that is probably opinion and
>> philosophical.

> One True Brace. It is not philosophical opinion, but rather Revealed
> TRVTH.
>

Whassa mattah witchoo Donal? Youse doin' dis on purpose an' enjoyin' it too,
right? O' am I da only wun dat dunnunnerstan' whatcha talkin' 'bout?

Revealed TRVTH? Is that Roman for Revealed Truth? As in ASTERIX THE GAVL?

L

--
Penguin Power! Nothing I say reflects the views of my employer

Laurent Duperval mailto:laurent....@cgi.ca
CGI - SARM Project Phone: (514) 391-9523

Darren New

unread,
May 20, 1999, 3:00:00 AM5/20/99
to
Donal K. Fellows wrote:
> Standard vectors
> have other advantages (much cheaper to create as a whole, and very
> cheap indexing since the index is an integer and can be used directly
> instead of requiring mapping to an internal form.)

This of course presupposes that the translation from whatever reality is
out there into integers in the range 0..N is inexpensive. I.e., in
accessing an integer-indexed array, the first step is to convert what
you want to find into a small integer, *then* perform the constant-time
index operation. The first step is about 80% of computer science. ;-)
Perhaps it's more true more often for scientific/mathematical programs.

Duncan Barclay

unread,
May 20, 1999, 3:00:00 AM5/20/99
to
In article <7ht5vn$p6d$1...@srv38s4u.cas.org>,

lvi...@cas.org writes:
>
> According to Bryan Oakley <oak...@channelpoint.com>:
>:I'll still take tcl and tk over C and Motif any day of the week, and the
>:weekends too.
>
> I will grant you that. However, Tk is in general a lot tougher than
> vanilla C standard filters... I never deal with any other kind of window
> apps other than Tk/Tcl, so perhaps it's not Tk specifically but event
> driven GUI apps that are tough to debug...
>

I may be an odd ball here, but I've never really had too much of a
problem in debugging GUI code which is event driven. I think this is
probably due to my electronics background. In an electronic system,
especially and analogue one, things are happening all the time at all
parts of the system and events can be generated all over the place.

<ANECDOTE>

When I was an undergraduate, my final year project involved writing a
6502 emulator in Occam. When some of my more software orientated friends
came to help me debug, they were blown away by the ammount of parallel
processes I had going on (i.e. lots of threads in today's fashion).
Some of these people were post-grads engaged in parallel processing
research...

It just seemed natural to me that the seperate hardware blocks within
the CPU model should operate concurrently - that's what they do in the
real hardware. Once I had explained the way I pictured the system,
and how it related to the hardware I was modelling, they became much
more comfortable with my code.
</ANECDOTE>

I wonder how good digital IC designers would be at dealing with
mutli-threaded/event driven software. I think that they would be pretty
good and might even be an asset to a project. They deal with
synchronisation and locking all the time...

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

Bryan Kelly

unread,
May 20, 1999, 3:00:00 AM5/20/99
to
RE: When I was an undergraduate, my final year project involved writing a

6502 emulator in Occam. When some of my more software orientated friends
came to help me debug, they were blown away by the ammount of parallel
processes I had going on (i.e. lots of threads in today's fashion).
Some of these people were post-grads engaged in parallel processing
research...

Tell me, do you think that EEs turned programmers tend to be better, same,
or worse programmers than CS (computer science) people? You seemed to have
turned it to your advantage and have mentioned some of the reasons. For
that kind of work (without saying anything about other kinds), I think you
are clearly correct. Most of the CS people I have worked with haven't a
clue as to how computers and peripherals really work. My hardware
background seems to enable me to understand system better and helps me
tremendously when I work on embedded systems. However, my experience shows
that many of the EEs make wretched software engineers.

Bryan


Bryan Kelly

unread,
May 20, 1999, 3:00:00 AM5/20/99
to
RE: Maps are mechanisms whereby you put a value in and get a

value out. They are *very* general indeed. Selecting the right kind
of map for a particular use requires deep thought on what exactly is
going on and what operations you want it to support with what
efficiency. Extensible perfect hashing (as used by Tcl) is one of the
best solutions for the general string|->something type of map where
the number of elements cannot be fixed by other means and run-time
update of both the domain and the range is required.

Hmmm <in deep thought> < vbg>

Sometimes I feel like I spend far too much time just sitting and thinking
about what I am about to do. Not even writing, just thinking. On the other
hand, my defect level is significantly lower than almost all of my peers.
(and despite apparent ego problems here, my peers and boss agree with this)

What is extensible perfect hashing. Did the inventors of the technique toss
in "perfect" so people would think highly of it, or is there another meaning
that I am not familiar with.

Bryan

PS: In Microsucks Outlook Express, this thread is about to fall off the
bottom. How long before it gets discarded. Maybe we should initiate a new
version of it.

BK


Cameron Laird

unread,
May 20, 1999, 3:00:00 AM5/20/99
to
In article <3743DD...@cnet.francetelecom.fr>,
Alexandre Ferrieux <alexandre...@cnet.francetelecom.fr> wrote:
>Donal K. Fellows wrote:

>>
>> In article <7ht5vn$p6d$1...@srv38s4u.cas.org>, <lvi...@cas.org> wrote:
>> > I will grant you that. However, Tk is in general a lot tougher than
>> > vanilla C standard filters... I never deal with any other kind of
>> > window apps other than Tk/Tcl, so perhaps it's not Tk specifically
>> > but event driven GUI apps that are tough to debug...
>>
>> I think you're right there. Sophisticated stuff is never going to be
>> all that easy to debug. Event-driven stuff is not all that easy to
>> reason about either
>
>But still so much easier than thread sync headaches :)
>
>-Alex

One of the great under-appreciated aspects about
Tcl. Not nearly enough people understand its
event model well enough to catch on how much safer
it is than conventional threaded work.
--

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

Cameron Laird

unread,
May 20, 1999, 3:00:00 AM5/20/99
to
In article <7hrmna$8p9$1...@srv38s4u.cas.org>, <lvi...@cas.org> wrote:
.
.
.

>Good luck finding a scripting language that is fast, flexible, enforces
>the strictness you want, but lets you code in your personal style. It's
>a grail that programmers sometimes spend significant portions of their
>lives seeking.
.
.
.
Camp followers are starting to set up concession
stands along the route. That is, languages such
as Pliant, Lua, Tcl itself in several aspects,
Forth, REBOL, ... give various metaprogramming
facilities and/or encourage expression of "personal
style". If you want fast-flexible-strict-..., but
want it "your way", there's a good chance you can
get very close to your grail using pieces that have
already been manufactured.

Cameron Laird

unread,
May 20, 1999, 3:00:00 AM5/20/99