Tcl misconceptions

[Bruce Stephens <b.stephens@isode.com>]

Tcl 8 and later (i.e., Tcl with its byte compiler) is quite different,
underneath, to previous Tcl's.  I suspect glossing over this is a
mistake, if you want to try translating it.

Tcl 8 is *not* just strings, internally.  

My understand of things is that strings have a special place, in that
they provide a format that ought always to exist, but the string form
need not be meaningful.

If you create a new kind of Tcl object, when you register it, you
provide two kinds of conversion: a way of producing a string from your
object, and a way of producing your internal form from a Tcl object
(of any form).  Your update-string procedure may not raise an error.
The produce-an-object-from-any conversion may raise an error.  For
example, the conversion which produces a list from an object may raise
an error.

Additionally, these are the only forms of conversion which you can
provide.  If you have a new kind of object (A, say) which really has a
nice list form, it can't really provide this except through its string
form, since there's no way of telling the relevant procedures about a
conversion A-to-list, so lindex (say) on an A will call
convert-any-to-list, which will convert A to string and then string to
list.  Your any-to-A can look to see if it's been given a list, and do
something special then, however.

(One could imagine more flexible ways of arranging new object, but I
suspect they won't be provided.  They probably wouldn't provide enough
to be worth the extra complexity involved.)

The string form need not be meaningful.  For example, the commercial
Tcl compiler in TclPro produces procedures which have a bytecode
internal form, but when you do something which asks for the string
form ("info body ...", say), you get a suitable string message.  So
manipulations of this are unlikely to be useful!  

Similarly, one could imagine other objects which only supported
conversions one way---from any to the object---with useless
conversions to string, with special operations which did useful things
with the object (as execution knows how to deal with bytecode
objects).

In conclusion, viewing Tcl just from the surface syntax is probably
the wrong way to understand it.  It's probably much better to try to
understand how the new Tcl objects work, and how they're dealt with by
the bytecode compiler/interpreter, in order to work out a sensible
translation.  Tk is definitely the wrong place to look, since this
still uses the legacy string interfaces: look at the Tcl
implementation itself, and the new APIs (Tcl_RegisterObjType,
Tcl_CreateObjCommand and things).