In article <email@example.com>, Erik Naggum <firstname.lastname@example.org> wrote:
> Charles Lin
>> Now, perhaps I completely misunderstood what Ousterhout did, but I was
>> under the impression that he said everything in Tcl (the external
>> representation) is a string. Why are we talking about internal
>> representations at all?
> because the internal representation in Tcl is the string.
In some implementations for some objects. Not all of either. Get
your facts straight Erik (by having a look at Tcl8 :^)
>> Internal representations aren't going to be important because they are
>> hidden from the user (mostly).
> I think you're missing the point all over the place. Tcl's purpose is to
> glue different applications together, but also to do something with the
> returned "values" (i.e., output) of these programs. of course we're
> dealing with interfaces where external representations will be used, but
> Tcl uses the same external representations for internal purposes, too.
> when you execute a numeric operation, the string is converted to a number,
> the operation is performed, and then converted back to a string. in
> contrast to this view, AWK converts a string to a number when it is used
> for a numeric purpose, and a number to a string when it is used for a
> string purpose, but not otherwise. (at least, this is what I have
> understood from what I have read about Tcl.)
Tcl (well, Tcl8) does better than AWK, in that when it converts a
string to a number (because it has been used numerically) it keeps the
old string representation around[*] in case the programmer refers to
that symbol in a string context, instead of having to convert back and
forth. The same is true for Tcl8 lists - then you program with them
you use a string representation of them, but when they are referred to
in a list context, an efficient internal list representation is
generated, and if the list is created internally in the program, then
a string representation may never actually exist at all (it would only
be created if the programmer did something like interpolating the list
into a string, as you'd expect.) This system of lazy type-conversion,
when coupled with an on-the-fly bytecode compiler (Tcl doesn't match
well with compilation to the JVM, compilation to native code is much
more difficult to make portable between architectures, and static
compilation is, in general, probably nigh-on impossible) gets the
performance boost that many of Tcl's detractors and advocates have
been after for years.
[* Naturally, if the numberic representation is then modified, the
string rep. is discarded and may need regenerating. But you would
have expected that...]
Donal K. Fellows http://r8h.cs.man.ac.uk:8000/ (SAY NO TO COMMERCIAL SPAMS!)
(work) email@example.com Dept. Comp. Sci, Univ. Manchester, U.K.
| firstname.lastname@example.org 6,Randall Place, Heaton, Bradford, U.K. (home)
+-> ++44-161-275-6137 Send correspondence to my office ++44-1274-401017 <-+