[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
not having read the common-lisp manual,
- To: info-lispm@mit-ai
- Subject: not having read the common-lisp manual,
- From: CSVAX.fateman at Berkeley
- Date: Sat ,19 Sep 81 00:01:55 EDT
- Cc: CSVAX.jkf@Berkeley, CSVAX.sklower@Berkeley
I would have thought the way to provide a common lisp basis (presumably for
transmittal of code) would be comparable to the way we run (in the same
Franz Lisp system) pieces of code in UCI Lisp, Maclisp, and even
Interlisp. (a subset of it, anyway).
Given a computer running X-lisp, you have a common-lisp-to X-lisp
translator (in the case of Franz, an adjunct to the compiler does this).
X-lisp-to common-lisp translators may be more difficult to write, but
then perhaps what should be encouraged is the development of strict
subsets of X-lisp for which common-lisp translators can be manufactured.
In the case of Franz, appropriate macro definitions are used at compile
time so that "loop" means any of 3 different things
depending upon source file language. At run-time, the user has
(a perhaps different) choice of "loop" macro.
There are difficulties in the case of debugging, if the programmer
was expecting, for example, the Interlisp run-time-environment.
The run-time environment COULD be patched up to look like the
"common lisp run-time environment", but this sounds to me like
a bad idea. Either we all have Ledit and Bitblt or none of us have it?
What this means is no one is restricted from defining and using Gumbies
some X-lisp, but if Gumbies have no counterpart in common-lisp, it
MAY happen that the programs using Gumbies are not transportable.
This is totally reasonable. In fact I thought that Griss had done
this type of thing.