a_tucker@paul.spu.edu (Andrew Tucker) asks:
<<<<<<
<< In a book I bought recently, the author implements a Forth-like script
<< language in what he calls a "threaded interpretive language". What are the
<< benefits/drawbacks of TILs compared to more traditional language
<< implementations are?

It doesn't seem quite appropriate to talk of a threaded interpretive
*language*, since threaded code interpretation is an implementation
technique, which shouldn't (needn't anyway) be reflected in language
design. Be that as it may, the original reference to threaded code is

J.D. Bell `Threaded Code' Comm. ACM 16,6 (June 1973) 370--372

where he talks a bit about the advantages. An interesting variant on
threaded code is indirect threaded code, which I know a bit about. This
has certainly been used for languages unlike Forth. In particular, it was
used in a successful portable Spitbol system, as described in:

I did my PhD under Tony McCann at Leeds and used the same technique to
implement a Setl interpeter. (This was in 1980. I believe it was revived
a few years ago and ported to IBM PC by some people at NYU, although I
haven't heard anything about that recently.) Later, Tony supervised at
least one more student who used indirect threaded code to implement
Pascal. I have no further details about this, though.

For indirect TC, the main advantages over generation of hard code are
portability and compact code (maybe not so important now). Its advantage
over source interpretation is efficiency. Compared to interpretation of
`conventional' virtual machine code, it has again advantages of
portability (only weak assumptions about wordlength are required, for
example) and very low interpretive overhead.
--