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] |
Maciej Stachowiak <mstachow@mit.edu> writes: > My understanding is that Tcl 8 uses non-string representations > internally sometimes, but is still meant to have the exact same > semantics as the old all-strings version. Thus, while looking at 8.0 > internals might provide helpful hints on how to be clever about > interpreting Tcl, it won't provide particularly deeper insight into > the semantics. That's supposed to be true. Sometimes it's only the documented semantics that are preserved, however. For example, in tcl7.6: % set a "1 2 3" 1 2 3 % lappend a 4 1 2 3 4 In tcl8.0: % set a "1 2 3" 1 2 3 % lappend a 4 1 2 3 4 Now, nobody's going to depend on either behaviour, so an implementation based on strings would be acceptable. I just think that looking at how Tcl itself does the compilation is likely to be easier (because it looks lots saner than having strings everywhere), and would produce a higher-quality interpreter/translator (or whatever you're trying to achieve). Simplifying how Tcl does things is also likely to be acceptable: expressions are recognised specially, for example, since they have their own syntax. % set a 2 2 % set b 3 3 % expr {$a*$b} 6 This is legal, since expr does its own variable expansion. Expressions without the extra braces are compiled *differently* to expressions with the braces. Since % set a 1+2 1+2 % set b 3 3 % expr $a*$b 7 (by the normal rules of expansion). With these values, expr {$a*$b} throws an error. Losing the syntax which doesn't have braces wouldn't hurt much. The first arguments of "if" and "while" and probably other things are also recognised as expressions. You're right though, these are details around the edges. A string-based interpretation is still likely to be acceptable. I'm just worried that it would be horribly slow, and that it would just be better to link in libtcl8.0 and spend the effort on working out how to exchange objects between the two languages.