Hello !
I'm looking for a LISP interpreter that would work
on either SunOS or DOS. (Or maybe a compiler if no
interpreter is available)
Can anybody help with a pointer ?
Thanx !
Tavi Ureche
····@info.polymtl.ca
In article <··········@lgrnd.goldstar.co.kr> Jong-Won Choi <jwchoi> writes:
>Most of (or all) Lisp implementaion is interpereter based. Also, most of (or
>all) of them have their compiler. Some has delivery system.
>I think you should read Lisp FAQ
And you should re-read it, as well as reading some papers on Lisp from after
1965. Very few modern implementations are interpreted at all; instead, they
use incremental compilation of the source code for the interactive environment.
The only interpreter-based Lisp of major consequence these days is the one
underlying GNU Emacs.
Stop spreading misinformation about Lisp.
Rich Alderson
--
Rich Alderson You know the sort of thing that you can find in any dictionary
of a strange language, and which so excites the amateur philo-
logists, itching to derive one tongue from another that they
know better: a word that is nearly the same in form and meaning
as the corresponding word in English, or Latin, or Hebrew, or
what not.
--J. R. R. Tolkien,
········@netcom.com _The Notion Club Papers_
Richard M. Alderson III (········@netcom.com) wrote:
: And you should re-read it, as well as reading some papers on Lisp from after
: 1965. Very few modern implementations are interpreted at all; instead, they
: use incremental compilation of the source code for the interactive environment.
: The only interpreter-based Lisp of major consequence these days is the one
: underlying GNU Emacs.
: Stop spreading misinformation about Lisp.
All the lisps that I have worked with, e.g. Clisp, kcl, akcl, dcl, ecl, mulisp
have an interpreter which interpret code, not compile it. I am sure
that there are a lot of implementations which behave like you say, but
the previous poster was in no way 'spreading misinformation'.
Regards, Pierpaolo.
In article <··················@netcom.com>, ········@netcom.com wrote:
:And you should re-read it, as well as reading some papers on Lisp from after
:1965. Very few modern implementations are interpreted at all; instead, they
:use incremental compilation of the source code for the interactive environment.
:Stop spreading misinformation about Lisp.
:
: Rich Alderson
:--
but in what way is incremental compilation different from interpretation?
i would think that an interpreter would still have to compile whatever you
gave it before it could be run through the cpu, right?
not being facetious here, i'm actually curious about this point ...
health,
-robin
--
Things fall Apart.
The Center cannot hold.
In article <························@sfsp114.slip.net>,
Krystal <·······@slip.net> wrote:
>but in what way is incremental compilation different from interpretation?
>i would think that an interpreter would still have to compile whatever you
>gave it before it could be run through the cpu, right?
>
>not being facetious here, i'm actually curious about this point ...
Here's an example. Using Macintosh Common Lisp (mcl), which does incremental
compilation, I evaluate the form
(defun square (x) (* x x))
and then I look at the result:
(symbol-function 'square)
the result I got from this was #<Compiled-function SQUARE #xNNNNNN>
where NNNNNN is a hexadecimal address.
If I evaluate the same two forms in Gnu Common Lisp (gcl), which does not do
incremental compilation, the result of (symbol-function 'square) is
(LAMBDA-BLOCK SQUARE (X) (* X X))
which indicates that SQUARE has not been compiled. To compile the function in
gcl, I can then type
(compile 'square)
and the response is #<compiled-function SQUARE>.
If I execute the function repetitively, such as
(time (dotimes (j 100000) (square j)))
the code runs much faster if SQUARE is compiled, than if it is interpreted.
(I found a factor of 2 difference using gcl).
Dave Seaman
[·······@slip.net (Krystal)]
| but in what way is incremental compilation different from
| interpretation? i would think that an interpreter would still have to
| compile whatever you gave it before it could be run through the cpu,
| right?
an interpreter looks at each form and evaluates it by means of deciding on
which functions or code to execute based on the form. a compiler would run
essentially the same code (subject to optimization), but the compiler would
have made the decisions on which code to run in advance, instead of
interleaved with the execution of that code.
you can write an interpreting evaluator for the simplest cases pretty
easily, and this is a usual exercise in Lisp courses to enhance the
students' understanding of how Lisp code is evaluated.
#<Erik 3020793485>
--
computers -- the only field where knowing the past
will make you less able to appreciate the present.
I happened ever to write a Common Lisp Interpreter about 3 years ago. It is not
very complete as commercial package, but it does cotain most functions
described in Guy Steele's book. And actually we have implemented CLOS on/using
it. It was in standard C and very portable. You can compile it on any platform
having standard C. I have it compiled on DOS, SunOS, Solaris and Linux.
If you are interested in using it and refining it, please contact:
········@cps.msu.edu
---- Michael Y. Chen