Date: Mon, 24 Feb 86 09:08:37 MST
From: shebs%utah-orion at utah-cs.arpa (Stanley Shebs)
Anyway, despite appearances :-), I'm more of an ideologist than an
ideologue, and so I'm interested in just how incompatible Common Lisp
and Scheme *really* are, and how difficult it would be to implement
one in the other. It's certainly possible, but since I haven't actually
tried hacking all this out, I'm not clear on the pitfalls.
I think the namespace problems are relatively easily overcome by
source-to-source translations, both going from Scheme to CL and from CL
to Scheme. Going one way you throw in a lot of FUNCALL's, and going the
other way you implement packages somehow and do some kludge to generate
names for variables which can stand for function bindings. The hard
problem in embedding Scheme in CL is tail recursion, which is impossible
to simulate in a natural way in portable Common Lisp. It may be more or
less easy in particular CL implementations (some are tail recursive
already, others may have compilers or stack-overflow handlers that can
be tweaked), but the only portable mechanism I know of is to do more or
less what Sussman and Steele's 1975 scheme interpreter did, which is to
use a driver loop of some kind, so that each procedure "returns" into
the driver loop in order to call another procedure at the same stack
level. This works but is quite unnatural and probably inefficient.
The hard technical problem in embedding CL in Scheme is implementing
multiple values smoothly. Various kludges are possible, such as the one
used by Maclisp, namely maintaining a set of global value registers.
Again, if you can hack the implementation directly, it can be pretty
straightforward (some already have multiple value returns internally).
A lesser problem is left-to-right argument evaluation, if CL ever
decides that that's necessary, but that can be forced using LET*.