[dkfellows]

The string interconvertibility (more formally, strings are the supertype of all other value types) only really applies to values that you can regard as being immutable. Mutable state instead goes into a named entity (even if it is an automatically-generated name); after all, if you can mutate the state, you need to care about the actual identity of the thing that holds that mutable entity. It also means that there's very little of the old spooky action-at-a-distance problems with Tcl; it's always clear where you are dealing with something that can confuse you, as you've explicitly got a name/handle.

Tcl did solve the problem of handling double-precision floating point number precision loss well. A numerical analyst fixed the code so that the automatic conversion generates the shortest string representation that will reparse to the same bit representation. It also avoids quite a few bugs in the C library in the process (on the grounds that different platforms have different bugs to each other).

[to3m]

As far as I can remember, this being 3.5 years (and several projects) ago, I had a lot of problems putting things in lists, because some list functions seemed to be cavalier about turning things into strings, and I'd end up with my carefully-constructed list of Tcl objects turning into a list of strings that were all "" :(

The obvious thing to do is just turn an object into a parseable string. So if you have a Texture object, which is a struct Texture at address 0x12345678, you might let this become a string, "(Texture * )0x12345678" (or similar). And then if you're expecting a Texture object you can check for not just a TclObj struct of the appropriate type, but also a string of the right format. I'm sure I found this unworkable, though, my recollection being that Tcl would call the free callback on the original object after turning it into a string, and so you'd quite possibly end up with a string representation of a dead object... but now that I say that out loud, it sounds super insane.

So maybe I'm recalling rightly. And then Tcl is still insane, and I stand by everything I said. It happens.

Or maybe I'm wrong... and that's good! Because I otherwise really did prefer it to Lua. I know exactly why Lua's C API is the way it is, but that doesn't make it any less horrid. And Tcl's shell-style syntax is way better for interactive use.

[dkfellows]

The usual problem is to do with managing list construction, and the usual answer is the [list] command, which Does The Right Thing for sane code. We also made sure that such lists go through the script evaluation engine cleanly (except for the first word, which will be forced to be interpreted as a command name, obviously). I think we (well, mostly me in this case) sorted this out properly in 8.5.

Still, we don't recommend tying objects with important lifetimes to values; Tcl really assumes that it can clone and release them as it sees fit (and effectively that it can interconvert through the serialization without problems). It's a pretty different design decision to what most programming languages go with, and has a lot of consequences, some really good and some quite irksome at times.

There's quite a few extension packages that do the sort of thing you're talking about without trouble. In particular, the packages for handling talking to DOM trees, DCOM interfaces, and JVMs all take this approach without becoming disaster zones. Another approach is to put the magical value in a variable and refer to that variable by name (which is a bit more easily done when it is an array element). I'm sure something could be worked out.