DN480300481

Subject: Should we have types in TCL? (apropos strings and list reps.) - DN [1]

dmlb@ragnet.demon.co.uk (Duncan Barclay) - 20 May 1999 - comp.lang.tcl

 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,
 dmlb@ragnet.demon.co.uk | the alcoholics, and the permanently stoned.
 ________________________________________________________________________