Hello,

The exquisite conciseness of the Tcl syntax (and language semantics) makes
me think about "drying" it even more, to get down to its very atoms.
Consider:

Initial code:

       foo "$x[bar $y]" [baz [gnu [gnats a b c] d e] f]

Quotes to explicit [scat];
Dollar reduction to unary [set]

       foo [scat [set x] [bar [set y]]] [baz [gnu [gnats a b c] d e] f]

Conversion to stack-based Forth-like evaluation. Dot "." means push a string
constant, MARK is a special arglist end marker, CALL invokes the named
function:
(MARK is a personal addition to Forths to handle varargs and allow to parse
a call tree without knowing the arities of the functions)

      MARK MARK .f MARK .e .d MARK .c .b .a .gnats CALL .gnu CALL .baz CALL
MARK MARK MARK .y .set CALL .bar CALL MARK .x .set CALL .scat CALL MARK .foo
CALL

Of course, this is comparable to what the bytecode VM does.
In fact, the strongest divergence between the bytecode VM and Forth-like
languages is the use of named variables.
With the example above, variables can at first glance be brushed off as "a
library concept" (since they are just in [set]'s mind).
But things are different for proc arguments, which in stack-based languages
are positional.
A first step can be made for simple cases like

     proc foo {x} {bar $x; ...}

by generating for the foo body:

    .1 .checkargceq CALL
    DUP MARK SWAP .bar CALL

IOW, as long as vars are not passed by name (i.e. accessed via upvar), they
can be factored out and mapped to stack positions, made available to the
body calls via automatically generated sequences of stack-juggling
primitives (DUP SWAP DIP etc...).

I know this is just half of the job (because of upvar), but I'm mentioning
this because on comp.lang.functional, in

http://groups.google.com/group/comp.lang.functional/browse_frm/thread/fcb495ea9cb277b2/32023
10b0247744a#3202310b0247744a

, Christopher Diggins, who is the author of the young and promising "Cat",
a new Forth dialect (actually, a descendant of Joy) , has just built on top
of it an extra layer named "Kitten",

http://www.cat-language.com/kitten.html

allowing to replace positional by named args.

 Now even for upvar, there are possibilities. Since in Tcl [upvar]ed vars
are accessed at runtime, it suffices to maintain enough data for a name
lookup in each stack frame.
In the 'foo' procedure above, the generated code can become:

     .1 .checkargceq CALL
    MARK .x .remembervars CALL
    DUP MARK SWAP .bar CALL

(the idea being that "1 2 3 MARK .x .y .z .remembervars CALL" stores the
binding between "x" and the stack address of "1", etc.)

The bottom line of all this is that, at least for the part described above,
Tcl could reasonably be "compiled" (through some adapted Kitten) to a
"mainstream" Forthish language.
This may sound of only academic interest. I'm not that sure, because the
Forth community has a track record of concern for speed and JIT compilation.
Cat already has a conversion from its bytecode to CIL. I would not be
surprised to see a JIT for x86 come into life.

Reactions ?

-Alex