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]

Re: Tcl misconceptions


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.