This is the mail archive of the guile@cygnus.com mailing list for the guile project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
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).