Should we have types in TCL? (apropos strings and list reps.)

0 views
Skip to first unread message

Duncan Barclay

unread,
May 20, 1999, 3:00:00 AM5/20/99
to
The ongoing discussions on the subtle differences that the object
representation code makes between strings and lists prompts the
following thoughts on the subject line.

Those new to Tcl have often been confused with the differences between
strings and lists that existed in Tcl <8.0. It is becoming
increasingly apparent that the internal representation of strings and
lists can lead to performance penalities and in some cases "not quite
right" things happening (viz. the concat thread).

Now we are hearing from Tcl internals experts that script writers need
to have a good understanding of how their data is represented
internally in Tcl. I think that this is moving Tcl away from some of
its original goals - to be a simple scripting language - into a more
complex language, with which people need the same levels of software
engineering expertise that is more associated with professional
programmers and compiled languages. I do not think this is helpful.

The following points hopefully explain why I think that exposing
internals of the Tcl implementation at the script level is not good.

I know of programmers who have developed Tcl interpreters for
specialied applications because Tcl is a great scripting language but
the Scriptics implememtation is not useful. Two examples I have used:
a small Tcl interpreter so that a Tk clone can be used inside a complex GUI
running under NeXTStep and Plan 9, and Another interpreter for testing
real time telecommications protocol stacks running in embedded
hardware and co-simulation platforms). The internal representations of
lists and strings in these cases is totally different from the
Scriptics implementation, thus code that is optimal on one interpreter
may be a pig on another.

This then leads to the thought of what happens when Scriptics change the
current implemention? All of our carefully constructed code which takes
best advantage of the current system slows down again.

In future versions of the Scriptics implementation it is conceivable
that variables which hold numeric data are optimised (this of course may
happen now). Now we have to learn how to deal with numeric data,
strings and lists - all of which pass over the script/interpreter
interface in the same way.

Additionally, exposing the internals of any implementation in an
undocumentated/unsanctioned manner has for a long time been discouraged by
software engineers as bad practise. Isn't this exactly what we are doing
at the moment?

A possible solution to these issues is to have typed variables at the
script level. A documented difference between strings and lists (and
whatever) will ensure that programmers do not accidentally write
sub-optimal code; will possibly help the just-in-time compilation;
enable code coverage tools to test more thoroughly and make scripts
future proof. Untyped variables would behave as they do now.

One can ensivage an implementation of typing which actually fits well
with the current interpreter (with the caveat that I'm not an expert on
Tcl 8 internals). Typing a variable would provide hints to the compiler,
strict type checking could be set via a tcl_ option.

Finally, we could also deal with some of the concerns over 8.1's
Unicode issues!

Duncan

Who is probably going to start using Hungarian notation (indicating the
type of a variable in name e.g. a string foo will be named sFoo) when
writing significant bits of Tcl even though I hate it!

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

Bryan Oakley

unread,
May 20, 1999, 3:00:00 AM5/20/99
to
[complete snippage of a short essay by Duncan Barclay
<dm...@ragnet.demon.co.uk> ]

You make some interesting points. I'll disgree with one point though -- I
don't think anyone needs a good understanding of tcl internals to write tcl.
It helps in optimization, but it is not strictly necessary to write good tcl
code.

Tcl is still, fundamentally, a very simple language to learn for most people
(*). I've lived for four years without knowing the peculiarities of the
concat command -- it always worked pretty much the way I expected it to. The
current concat thread is facinating, but irrelevant (to me) at the same
time. I've also survived the bytecode era without sweating too much about
whether something has a list representation, a string representation, or
both.

For the vast majority of programmers and for the vast majority of programs
tcl is used for, I'd wager it's not a big issue. It's only important when
trying to squeeze out the maximum performance possible. And in that regard,
tcl is no different than C or any other language. All languages have lots of
hidden secrets one can exploit to squeeze out a little bit more performance.
Of course, with tcl, any time performance is really important, you are
empowered to code the perfomance sensitive stuff in C (or any other language
you can link with C for that matter)

So, with all that being said, I don't see the need for variable typing. The
fact that tcl isn't typed is something I _really_ like about Tcl. Even
though writing fully optimized tcl can be a bit tricky, writing sufficiently
fast tcl is ridiculously easy. In my opinion, based largely on my own
personal experience. So I say, let's keep the language simple.

(*) especially those who have no problem _un_learning what they know about
other more traditional languages.


Chang LI

unread,
May 21, 1999, 3:00:00 AM5/21/99
to
Duncan Barclay wrote:
>
> The ongoing discussions on the subtle differences that the object
> representation code makes between strings and lists prompts the
> following thoughts on the subject line.
>
> Those new to Tcl have often been confused with the differences between
> strings and lists that existed in Tcl <8.0. It is becoming
> increasingly apparent that the internal representation of strings and
> lists can lead to performance penalities and in some cases "not quite
> right" things happening (viz. the concat thread).
>

I agree. I confused Tcl's list with the Lisp's list in the beginning.
You'd better think list is only a special kind of string. You can apply
string operations on list. There are many quirks there. For example,
is [list a b] equal to the {a b}?



> Now we are hearing from Tcl internals experts that script writers need
> to have a good understanding of how their data is represented
> internally in Tcl. I think that this is moving Tcl away from some of
> its original goals - to be a simple scripting language - into a more
> complex language, with which people need the same levels of software
> engineering expertise that is more associated with professional
> programmers and compiled languages. I do not think this is helpful.
>

It is better you know the internal representation but not necessary.



> The following points hopefully explain why I think that exposing
> internals of the Tcl implementation at the script level is not good.
>
> I know of programmers who have developed Tcl interpreters for
> specialied applications because Tcl is a great scripting language but
> the Scriptics implememtation is not useful. Two examples I have used:
> a small Tcl interpreter so that a Tk clone can be used inside a complex GUI
> running under NeXTStep and Plan 9, and Another interpreter for testing
> real time telecommications protocol stacks running in embedded
> hardware and co-simulation platforms). The internal representations of
> lists and strings in these cases is totally different from the
> Scriptics implementation, thus code that is optimal on one interpreter
> may be a pig on another.
>
> This then leads to the thought of what happens when Scriptics change the
> current implemention? All of our carefully constructed code which takes
> best advantage of the current system slows down again.
>

I think the majority reason to get performance down is to adapt the
unicode. Some fast algorithms that suitable for 8bit string is not
suitable
for 16bit string. It applies for other scripting lanagure such as Perl.


> In future versions of the Scriptics implementation it is conceivable
> that variables which hold numeric data are optimised (this of course may
> happen now). Now we have to learn how to deal with numeric data,
> strings and lists - all of which pass over the script/interpreter
> interface in the same way.
>

I do not think so.

> Additionally, exposing the internals of any implementation in an
> undocumentated/unsanctioned manner has for a long time been discouraged by
> software engineers as bad practise. Isn't this exactly what we are doing
> at the moment?
>
> A possible solution to these issues is to have typed variables at the
> script level. A documented difference between strings and lists (and
> whatever) will ensure that programmers do not accidentally write
> sub-optimal code; will possibly help the just-in-time compilation;
> enable code coverage tools to test more thoroughly and make scripts
> future proof. Untyped variables would behave as they do now.
>

No typed variables. A developer knows the variable type he has used in
mind.
For computer let it guess.


> One can ensivage an implementation of typing which actually fits well
> with the current interpreter (with the caveat that I'm not an expert on
> Tcl 8 internals). Typing a variable would provide hints to the compiler,
> strict type checking could be set via a tcl_ option.
>
> Finally, we could also deal with some of the concerns over 8.1's
> Unicode issues!
>

There are other ways to deal with the performance.

> Duncan
>
> Who is probably going to start using Hungarian notation (indicating the
> type of a variable in name e.g. a string foo will be named sFoo) when
> writing significant bits of Tcl even though I hate it!
>

After several years use of Hungarian notation I feel the advantages to
use simple and short variable name in Unix style. Just use s and l make
the code much easier to read and understand than sString and lList.
Now I get back to like the unix naming scheme.



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

--
--------------------------------------------------------------
Chang LI, Neatware
email: cha...@neatware.com
web: http://www.neatware.com
--------------------------------------------------------------

Jeffrey Hobbs

unread,
May 21, 1999, 3:00:00 AM5/21/99
to Duncan Barclay
Duncan Barclay wrote:
> Those new to Tcl have often been confused with the differences between
> strings and lists that existed in Tcl <8.0. It is becoming
> increasingly apparent that the internal representation of strings and
> lists can lead to performance penalities and in some cases "not quite
> right" things happening (viz. the concat thread).
>
> Now we are hearing from Tcl internals experts that script writers need
> to have a good understanding of how their data is represented
> internally in Tcl. I think that this is moving Tcl away from some of

I think the concat thread was more of an interesting enlightenment into
the vaguaries of Tcl_Obj's dual representation ability. While the base
of the topic was to speed up concat for list objects, the intricacies
that arose in explaining the error in my initial patch for Tcl_ConcatObj
are more of an AHA! for potential developers of the internals, rather
than something that the regular Tcl user must worry about.

> I know of programmers who have developed Tcl interpreters for
> specialied applications because Tcl is a great scripting language but
> the Scriptics implememtation is not useful. Two examples I have used:
> a small Tcl interpreter so that a Tk clone can be used inside a complex GUI
> running under NeXTStep and Plan 9, and Another interpreter for testing
> real time telecommications protocol stacks running in embedded
> hardware and co-simulation platforms). The internal representations of
> lists and strings in these cases is totally different from the
> Scriptics implementation, thus code that is optimal on one interpreter
> may be a pig on another.

What was the impetus behind the changes here? What version of Tcl did
they originate from? Aside from the current tribulations about UTF
string calculations in Tcl8.1, the Tcl8 base object types seem fairly
optimal in their interrelations. As Alex pointed out well, the lazy
conversion and dual type existence can be very beneficial - if watched
out for. The changes above seem to warrant calling this miniTcl a
distant derivative cousin, rather than a close sibling.

> happen now). Now we have to learn how to deal with numeric data,
> strings and lists - all of which pass over the script/interpreter
> interface in the same way.
>

> Additionally, exposing the internals of any implementation in an
> undocumentated/unsanctioned manner has for a long time been discouraged by
> software engineers as bad practise. Isn't this exactly what we are doing
> at the moment?

I think a lot of this has to do with paradigm shifts that people have to
get accustomed to. Tcl underwent some significant changes that allow for
new, or encouraging the changing of old programming paradigms in the Tcl
dialect (ie - lists). The problem is exacerbated by the lack of good
resources, docs or books that work with only the new paradigm. Old users
have to change habits. New users get confused because the read something
in an older book, and then get contradictory advice on the newsgroup.

With Tcl8, people are having to confront with a front-end typeless
language that has internal data types for efficiency reasons. It is
easy to get people to not write bad code if this is well doc'ed in their
first references. For example, if I know that I have a var with a list:
set a [list ...]
I should know that the best way to check if it isn't empty is:
if {[llength $a]}
and not
if {[string compare $a {}]}

while both are legal, the first keeps with the nature of $a, and is
thus faster. However, should we need to use $a as a list, then so be it.

> A possible solution to these issues is to have typed variables at the
> script level. A documented difference between strings and lists (and

...


> Tcl 8 internals). Typing a variable would provide hints to the compiler,
> strict type checking could be set via a tcl_ option.

And then strict type checking doesn't allow the two forms above to
check for a non-empty var? That's a VERY heavy hit on backwards
compatibility, because often you want the polymorphism of an arg,
and you don't want to have to add casting routines. If you work
with the new paradigms, then you already have what you want.

For a list var, instead of:
set a {}
do set a [list]

I actually do that in some code now. Unfortunately, you can't do that
efficiently for ints, but I think we aren't really losing anything there.

> Who is probably going to start using Hungarian notation (indicating the
> type of a variable in name e.g. a string foo will be named sFoo) when

An interestingly drastic alternative, that might actually be a good way
to bring newbies into the new Tcl paradigm, but are probably not necessary
for users comfy with the state of affairs.

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

Jeffrey.Hobbs.vcf

Paul Duffin

unread,
May 21, 1999, 3:00:00 AM5/21/99
to
Duncan Barclay wrote:
>
> The ongoing discussions on the subtle differences that the object
> representation code makes between strings and lists prompts the
> following thoughts on the subject line.
>
> Those new to Tcl have often been confused with the differences between
> strings and lists that existed in Tcl <8.0. It is becoming
> increasingly apparent that the internal representation of strings and
> lists can lead to performance penalities and in some cases "not quite
> right" things happening (viz. the concat thread).
>
> Now we are hearing from Tcl internals experts that script writers need
> to have a good understanding of how their data is represented
> internally in Tcl. I think that this is moving Tcl away from some of
> its original goals - to be a simple scripting language - into a more
> complex language, with which people need the same levels of software
> engineering expertise that is more associated with professional
> programmers and compiled languages. I do not think this is helpful.
>

There is one very simple rule which helps you to right efficient
code without worrying about the implementation.

Treat an <X> as an <X> and a <Y> as a <Y> and minimise
conversions

Obviously this does require that the docs are correct and explain
what type each command treats its arguments as.

> The following points hopefully explain why I think that exposing
> internals of the Tcl implementation at the script level is not good.
>

> [snipped]

Of course exposing internals is never a good idea and Tcl 8 did an
awfully good job preserving the behaviour; however performance
and resource usage always leak out of the nice black box you have
constructed for yourselves. This means that someone who knows how
the black box works will be able to right more efficient code than
someone who doesn't.



> This then leads to the thought of what happens when Scriptics change the
> current implemention? All of our carefully constructed code which takes
> best advantage of the current system slows down again.
>

That is true for Tcl just as it is true to a lesser extent for C
compilers and to a similar extent for C++ compilers.

> In future versions of the Scriptics implementation it is conceivable
> that variables which hold numeric data are optimised (this of course may

> happen now). Now we have to learn how to deal with numeric data,
> strings and lists - all of which pass over the script/interpreter
> interface in the same way.
>

As long as you hold to the rule described above you will be protected.

> Additionally, exposing the internals of any implementation in an
> undocumentated/unsanctioned manner has for a long time been discouraged by
> software engineers as bad practise. Isn't this exactly what we are doing
> at the moment?
>

No. Tcl programmers do not "need" to know the internals to write Tcl
programs, it just helps. Just like you do not need to know a computers
instruction set, or how the compiler's code generator works, or what
optimisations a compiler can do for you and those it can't in order to
program in C, it just helps.

> [snipped typed variables]
>
> Duncan


>
> Who is probably going to start using Hungarian notation (indicating the
> type of a variable in name e.g. a string foo will be named sFoo) when

> writing significant bits of Tcl even though I hate it!
>

Its either that or lots of comments.

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

Paul Duffin

unread,
May 21, 1999, 3:00:00 AM5/21/99
to
Jeffrey Hobbs wrote:
>
> Duncan Barclay wrote:
> [snipped comments on concat discussion]

It would be a way of detecting when users had made a mistake by treating
strings as lists or vice versa, it would not be a backward compatability
issue because untyped variables behave as they currently do.

> For a list var, instead of:
> set a {}
> do set a [list]
>
> I actually do that in some code now. Unfortunately, you can't do that
> efficiently for ints, but I think we aren't really losing anything there.
>

Actually you will be pleased to know that the byte compiler does create
an integer object if it finds a literal string which looks like one.

> > Who is probably going to start using Hungarian notation (indicating the
> > type of a variable in name e.g. a string foo will be named sFoo) when
>
> An interestingly drastic alternative, that might actually be a good way
> to bring newbies into the new Tcl paradigm, but are probably not necessary
> for users comfy with the state of affairs.
>

--

Jeffrey Hobbs

unread,
May 21, 1999, 3:00:00 AM5/21/99
to Paul Duffin
Paul Duffin wrote:
> Jeffrey Hobbs wrote:
> > Duncan Barclay wrote:
> > > A possible solution to these issues is to have typed variables at the
> > > script level. A documented difference between strings and lists (and
> > ...
> > > Tcl 8 internals). Typing a variable would provide hints to the compiler,
> > > strict type checking could be set via a tcl_ option.
> >
> > And then strict type checking doesn't allow the two forms above to
> > check for a non-empty var? That's a VERY heavy hit on backwards
> > compatibility, because often you want the polymorphism of an arg,

> It would be a way of detecting when users had made a mistake by treating


> strings as lists or vice versa, it would not be a backward compatability
> issue because untyped variables behave as they currently do.

Then you would have to be very careful that newbies don't start using
types, and then get confused on the whole typed vs untyped var. On
the whole, it seems excessive over the flexibility Tcl currently provides.

It would be an interesting compiler/Tcl option to set a flag that would
profile or report object conversions (in some not-too-verbose manner).
You could put that in the current version as a manner of checking
programming style/code efficiency.

> > I actually do that in some code now. Unfortunately, you can't do that
> > efficiently for ints, but I think we aren't really losing anything there.

> Actually you will be pleased to know that the byte compiler does create


> an integer object if it finds a literal string which looks like one.

I did discover this nice tidbit when doing the string patch. In fact, I
did a lot of munging in areas of the core that I hadn't touched much before,
to get a better understanding of what goes on. I also found that there are
a lot of routines down there that I would love to see exported. Ah well...

Jeffrey.Hobbs.vcf

Alexandre Ferrieux

unread,
May 21, 1999, 3:00:00 AM5/21/99
to
Jeffrey Hobbs wrote:
>
> It would be an interesting compiler/Tcl option to set a flag that would
> profile or report object conversions (in some not-too-verbose manner).
> You could put that in the current version as a manner of checking
> programming style/code efficiency.

Actually in private e-mail Paul promised me to consider this possibility
in Feather at some future date. Maybe if we are two the priority will
get boosted :)

-Alex

Alexandre Ferrieux

unread,
May 21, 1999, 3:00:00 AM5/21/99
to Jeffrey Hobbs
Jeffrey Hobbs wrote:
>
> With Tcl8, people are having to confront with a front-end typeless
> language that has internal data types for efficiency reasons.

Jeff, you know how loudly I applause to that. Now why didn't you write
the sentence above in response to:

http://www.deja.com/=dnc/getdoc.xp?AN=475783868

Now what's nice is that in the meantime Paul has somewhat yielded to the
point (though never saying clearly so :), so I guess that Feather will,
after all, allow people to reason purely at string level if they
wish/must/don't care.

-Alex

lvi...@cas.org

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

:Jeffrey Hobbs wrote:
:> With Tcl8, people are having to confront with a front-end typeless

:> language that has internal data types for efficiency reasons. It is
:> easy to get people to not write bad code if this is well doc'ed in their

Yes, exactly. In the early Tcl days, each variable paid a heavy price
because there was only one or two data types and everything had to be
coded to account for that. As new Tcl releases arrived, programmers would
discover that one representation now did better than another (lists vs
arrays, for instance). Now, with Tcl 8.1, another shift has occurred.
One has to decide - do I continue to pay the old price (or even a
heavier new price) or do I rewrite to pay less in terms of performance
or memory use, etc. With Tcl 8.1.1, yet another shift will occur. With
Tcl 9.0, I would imagine yet ANOTHER shift will occur.

If one doesn't want to deal with the vagarities of script performance
shifts, then writing the performance sensitive portions in C or assembler
is an option - however there's no guarantees even there, right? Because
if the underlying interpreter takes a major design shift (Tcl_Objs, Unicode,
etc.) then even the C code has to change.

The only way to avoid having to rewrite one's Tcl related code appears
to be to avoid any future upgrades.

Lest one think that Tcl is unique in this, I've heard tales from my
C++ programming cohorts regarding the impacts of compiler changes on
template code, I've had horrors over the past months modifying Perl
modules to compile under the current development release, upgrades to the
OS has caused tty driver and disk mount code to change almost every release,
etc.

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

Duncan Barclay

unread,
May 21, 1999, 3:00:00 AM5/21/99
to
In article <3744F3...@neatware.com>,
Chang LI <cha...@neatware.com> writes:
> Duncan Barclay wrote:

...


>> A possible solution to these issues is to have typed variables at the
>> script level. A documented difference between strings and lists (and

>> whatever) will ensure that programmers do not accidentally write
>> sub-optimal code; will possibly help the just-in-time compilation;
>> enable code coverage tools to test more thoroughly and make scripts
>> future proof. Untyped variables would behave as they do now.
>
> No typed variables. A developer knows the variable type he has used
> in mind. For computer let it guess.

I think that this is the crux of the problem for me. We are currently
letting the computer guess and because it is fallible it uses very
sophisticated multiple representations internally. This sophistication
can be exploited to gain best performance but the internals of the
implenementation have been exposed.

>> Duncan


>>
>> Who is probably going to start using Hungarian notation (indicating the
>> type of a variable in name e.g. a string foo will be named sFoo) when

>> writing significant bits of Tcl even though I hate it!
>>
>

> After several years use of Hungarian notation I feel the advantages to
> use simple and short variable name in Unix style. Just use s and l make
> the code much easier to read and understand than sString and lList.
> Now I get back to like the unix naming scheme.

I agree with you and your example illustrates why I don't really like
Hungarian notation, but in a large program your are going to have more
than one string and list!

Duncan

Duncan Barclay

unread,
May 21, 1999, 3:00:00 AM5/21/99
to
In article <374549...@mailserver.hursley.ibm.com>,

Paul Duffin <pdu...@mailserver.hursley.ibm.com> writes:
>
> There is one very simple rule which helps you to right efficient
> code without worrying about the implementation.
>
> Treat an <X> as an <X> and a <Y> as a <Y> and minimise
> conversions
>
> Obviously this does require that the docs are correct and explain
> what type each command treats its arguments as.

But aren't we them implicity using Tcl as a typed language but without
the support that is useful to programmers which is usually associated
with typed languages? How does one programmer communicate his intent to
another programmer if the variable is only typed by context (there have
been times when I've struggled to understand why some of the code
examples you ave posted work as strings/lists ;-))?

>> The following points hopefully explain why I think that exposing
>> internals of the Tcl implementation at the script level is not good.
>>
>> [snipped]
>
> Of course exposing internals is never a good idea and Tcl 8 did an
> awfully good job preserving the behaviour; however performance
> and resource usage always leak out of the nice black box you have
> constructed for yourselves. This means that someone who knows how
> the black box works will be able to right more efficient code than
> someone who doesn't.

Until the internals change...

>> This then leads to the thought of what happens when Scriptics change the
>> current implemention? All of our carefully constructed code which takes
>> best advantage of the current system slows down again.
>>
>
> That is true for Tcl just as it is true to a lesser extent for C
> compilers and to a similar extent for C++ compilers.

And is why things like the register declaration in C are being removed
(what used to be a valid approach when compiler technology was poor is
now a problem and with register short architectures like the i386
actually hurt the compiler). Exposing the internals always has the
potential for abuse and future problems (see Larry's posting elsewhere
in the thread for an example).



>> In future versions of the Scriptics implementation it is conceivable
>> that variables which hold numeric data are optimised (this of course may
>> happen now). Now we have to learn how to deal with numeric data,
>> strings and lists - all of which pass over the script/interpreter
>> interface in the same way.
>>
>
> As long as you hold to the rule described above you will be protected.

But it is hard to write code that does that, a language is there to make
a programmer's life easier, if not we would all be hacking assembler.

Duncan Barclay

unread,
May 21, 1999, 3:00:00 AM5/21/99
to
In article <37453E6C...@icn.siemens.de>,
Jeffrey Hobbs <Jeffre...@icn.siemens.de> writes:

> Duncan Barclay wrote:
>
> > I know of programmers who have developed Tcl interpreters for >
> specialied applications because Tcl is a great scripting language
> but > the Scriptics implememtation is not useful. Two examples I
> have used: > a small Tcl interpreter so that a Tk clone can be used
> inside a complex GUI > running under NeXTStep and Plan 9, and
> Another interpreter for testing > real time telecommications
> protocol stacks running in embedded > hardware and co-simulation
> platforms). The internal representations of > lists and strings in
> these cases is totally different from the > Scriptics
> implementation, thus code that is optimal on one interpreter > may
> be a pig on another.
>
> What was the impetus behind the changes here? What version of Tcl did
> they originate from?

Both of them were are combination of using some of the core guts from
Tcl 7.something and restricting functionality for the application. In
the case of the embedded Tcl I belive that the interpreter is actually
split over two CPUs - part running on the testing host and part running
on the embedded system.

<string stuff snipped>

> The changes above seem to warrant calling this miniTcl a distant
> derivative cousin, rather than a close sibling.

Oh certainly, the point I wanted to make is that Tcl is a good scripting
language and that the implementation isn't always the Scriptics one!

> > Additionally, exposing the internals of any implementation in an >
> undocumentated/unsanctioned manner has for a long time been
> discouraged by > software engineers as bad practise. Isn't this
> exactly what we are doing > at the moment?
>
> I think a lot of this has to do with paradigm shifts that people have to
> get accustomed to. Tcl underwent some significant changes that allow for
> new, or encouraging the changing of old programming paradigms in the Tcl
> dialect (ie - lists). The problem is exacerbated by the lack of good
> resources, docs or books that work with only the new paradigm. Old users
> have to change habits. New users get confused because the read something
> in an older book, and then get contradictory advice on the newsgroup.

Agreed.

> For a list var, instead of:
> set a {}
> do set a [list]

What about

proc declare {type variableName} {

switch -exact -- $type {

list {

upvar $variableName v
set v [list]

}

}

return
}

....

declare list a

...

Won't this make it clearer for other programmer's (or yourself) when
reviewing code at a later date?

Duncan

P.S. I wish my news reader groked your vcard!

Bryan Kelly

unread,
May 22, 1999, 3:00:00 AM5/22/99
to
Hold on a second here. Maybe we should reconsider some things here.

First, my origin ( A sophisticated way of saying where I'm coming from)
I am new to expect, and barely into tcl by way of expect. I see expect and
tcl as easy to use tools to accomplish tasks. The focus seems to be on easy
to use. Example: a peer where I work is writing expect scripts but takes
great exception to his output being called a program, and ever greater
offense at being called a programmer. (Admittedly extreme and rather
absurd, but a true and fitting example)

In a like manner, many think of these tools are viewed not as a programming
language, but as a tool to get some task done. All the while avoiding the
concept of programming.

Re-focus a bit.

If we go too far in digging into the internals of tcl, worrying about all
the nuances, and declaring types, then is it possible we are loosing sight
of the original purpose of tcl / expect? Could this be turning these tools
into something they are not? Eventually they will become so complex that a
study course is required to perform even the simple tasks.

Those who want such detailed knowledge of the internal structures should
transition into C or some other language where they do indeed have control
of such things. (I love embedded programming in both C and in assembly
language) Expect and tcl are solving some problems that for me would be a
real PIA in C. They ( tcl and C for example) are completely different
perspectives of programming (read that "getting computers to do what we want
them to do) and one should not expect each to do what the other was intended
to do.

Bryan


Donal K. Fellows

unread,
May 24, 1999, 3:00:00 AM5/24/99
to
In article <7i227j$18mk$1...@computer.my.domain>,

Duncan Barclay <dm...@ragnet.demon.co.uk> wrote:
> Now we are hearing from Tcl internals experts that script writers
> need to have a good understanding of how their data is represented
> internally in Tcl. I think that this is moving Tcl away from some
> of its original goals - to be a simple scripting language - into a
> more complex language, with which people need the same levels of
> software engineering expertise that is more associated with
> professional programmers and compiled languages. I do not think this
> is helpful.

No, you do not. Code it any way you want. Just be aware that some
patterns of code are faster than others for the same task. Usually
these optimisations apply to code how you would tend to write it
anyway - this is a Good Thing.

The only time you really need to watch out for performance is when you
are handling large amounts of data in Tcl. Write your code however
you want, and think of performance stuff as something to be applied
afterwards if you feel like it. That is how the experts (or at least
this one) do it when writing apps. (Libraries are a little different,
as you can easily imagine.)

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>

Paul Duffin

unread,
May 24, 1999, 3:00:00 AM5/24/99
to
Duncan Barclay wrote:
>
> In article <374549...@mailserver.hursley.ibm.com>,
> Paul Duffin <pdu...@mailserver.hursley.ibm.com> writes:
> >
> > There is one very simple rule which helps you to right efficient
> > code without worrying about the implementation.
> >
> > Treat an <X> as an <X> and a <Y> as a <Y> and minimise
> > conversions
> >
> > Obviously this does require that the docs are correct and explain
> > what type each command treats its arguments as.
>
> But aren't we them implicity using Tcl as a typed language but without
> the support that is useful to programmers which is usually associated
> with typed languages? How does one programmer communicate his intent to
> another programmer if the variable is only typed by context (there have
> been times when I've struggled to understand why some of the code
> examples you ave posted work as strings/lists ;-))?
>

Whether or not a language supports (exposes) types I think in terms
of types. This address is an object of this type, that variable is
an object of that type etc. Just because in the strictest sense of the
word Tcl does not have types (only strings) does not mean that I should
stop thinking this way.

> >> The following points hopefully explain why I think that exposing
> >> internals of the Tcl implementation at the script level is not good.
> >>
> >> [snipped]
> >
> > Of course exposing internals is never a good idea and Tcl 8 did an
> > awfully good job preserving the behaviour; however performance
> > and resource usage always leak out of the nice black box you have
> > constructed for yourselves. This means that someone who knows how
> > the black box works will be able to right more efficient code than
> > someone who doesn't.
>
> Until the internals change...
>

Of course.

> >> This then leads to the thought of what happens when Scriptics change the
> >> current implemention? All of our carefully constructed code which takes
> >> best advantage of the current system slows down again.
> >>
> >
> > That is true for Tcl just as it is true to a lesser extent for C
> > compilers and to a similar extent for C++ compilers.
>
> And is why things like the register declaration in C are being removed
> (what used to be a valid approach when compiler technology was poor is
> now a problem and with register short architectures like the i386
> actually hurt the compiler). Exposing the internals always has the
> potential for abuse and future problems (see Larry's posting elsewhere
> in the thread for an example).
>
> >> In future versions of the Scriptics implementation it is conceivable
> >> that variables which hold numeric data are optimised (this of course may
> >> happen now). Now we have to learn how to deal with numeric data,
> >> strings and lists - all of which pass over the script/interpreter
> >> interface in the same way.
> >>
> >
> > As long as you hold to the rule described above you will be protected.
>
> But it is hard to write code that does that, a language is there to make
> a programmer's life easier, if not we would all be hacking assembler.
>

I don't know why it is hard to write code that does that, you just have to
be careful. If you are not careful enough (or read the docs and not the
source ;-)) then your program does not break it just goes a bit slower.

Jeffrey Hobbs

unread,
May 25, 1999, 3:00:00 AM5/25/99
to Duncan Barclay
Duncan Barclay wrote:
> What about
> proc declare {type variableName} {
> switch -exact -- $type {
> list {
> upvar $variableName v
> set v [list]
> }
> ....
> declare list a
> ...
> Won't this make it clearer for other programmer's (or yourself) when
> reviewing code at a later date?

Something like that would work, and be a good way to know what the
intent of the var is (someone also mentioned using Hungarian notation).
Of course, this doesn't change the mutability of the actual object later.

> P.S. I wish my news reader groked your vcard!

That's just a cute feature of Netscape, and doesn't have any interesting
info it.

Jeffrey.Hobbs.vcf
Reply all
Reply to author
Forward
0 new messages