From: Matt Austern
Subject: Re: Interpreters (Re: Comparing productivity: LisP against C++ (was Re: Reference Counting))
Date:
Message-ID: <MATT.95Jan21135219@physics7.berkeley.edu>
In article <·················@cfdevx1.lehman.com> ···@lehman.com (Rick Busdiecker) writes:
> I think that there is a common misconceptions that Lisp is an
> ``interpreted language''. In fact, there is nothing to prevent anyone
> from building either a Lisp or a C++ in any of these configurations:
> 1. Compiler and interpreter.
> 2. Compiler with no interpreter
> 3. Interpreter with no compiler
That's not really true. Every dialect of lisp I've ever heard of
includes the function eval. Once you have eval, you have a lisp
interpreter; the top-level read-eval-print loop is just a frill.
That's one reason why compiled lisp code is a bit unusual: the
run-time library has to include the full interpreter.
--
--matt
From: Paul Wallich
Subject: Re: Interpreters (Re: Comparing productivity: LisP against C++ (was Re: Reference Counting))
Date:
Message-ID: <3fs91e$hap@panix2.panix.com>
In <··················@physics7.berkeley.edu> ····@physics7.berkeley.edu (Matt Austern) writes:
>In article <·················@cfdevx1.lehman.com> ···@lehman.com (Rick Busdiecker) writes:
>> I think that there is a common misconceptions that Lisp is an
>> ``interpreted language''. In fact, there is nothing to prevent anyone
>> from building either a Lisp or a C++ in any of these configurations:
>> 1. Compiler and interpreter.
>> 2. Compiler with no interpreter
>> 3. Interpreter with no compiler
>That's not really true. Every dialect of lisp I've ever heard of
>includes the function eval. Once you have eval, you have a lisp
>interpreter; the top-level read-eval-print loop is just a frill.
Maybe, maybe not. One of the problems here is definitional, however:
it's quite easy to build an incrementally-compiled lisp with no
interpreter at all: read-eval-print becomes something like
read-compile-apply-print (where the apply step probably isn't a
real apply, but rather a function call to the thing or a wrapper
that contains it). I've heard this is often easier because you
don't have to verify that the compiler and interpreter do the same
thing.
>That's one reason why compiled lisp code is a bit unusual: the
>run-time library has to include the full interpreter.
Or something that resembles the interpreter or compiler closely
enough for government work...
paul
From: Jeff Dalton
Subject: Re: Interpreters (Re: Comparing productivity: LisP against C++ (was Re: Reference Counting))
Date:
Message-ID: <D2x5xA.91y@cogsci.ed.ac.uk>
In article <··········@panix2.panix.com> ··@panix.com (Paul Wallich) writes:
>In <··················@physics7.berkeley.edu> ····@physics7.berkeley.edu (Matt Austern) writes:
>
>>In article <·················@cfdevx1.lehman.com> ···@lehman.com (Rick Busdiecker) writes:
>
>>> I think that there is a common misconceptions that Lisp is an
>>> ``interpreted language''. In fact, there is nothing to prevent anyone
>>> from building either a Lisp or a C++ in any of these configurations:
>>> 1. Compiler and interpreter.
>>> 2. Compiler with no interpreter
>>> 3. Interpreter with no compiler
>
>>That's not really true. Every dialect of lisp I've ever heard of
>>includes the function eval. Once you have eval, you have a lisp
>>interpreter; the top-level read-eval-print loop is just a frill.
>
>Maybe, maybe not. One of the problems here is definitional, however:
>it's quite easy to build an incrementally-compiled lisp with no
>interpreter at all: read-eval-print becomes something like
>read-compile-apply-print [...]
True. PopLog Common Lisp is an example.
>>That's one reason why compiled lisp code is a bit unusual: the
>>run-time library has to include the full interpreter.
>
>Or something that resembles the interpreter or compiler closely
>enough for government work...
*Lisp* does not require that the run-time library include the
compiler or the interpreter. *Common Lisp*'s run-time includes
the functions eval, compile, and compile-file. But even then
what's in the library might not be what you expect. For instance,
the KCL compiler emits C code and then runs the C compiler.
That doesn't make the C compiler part of KCL's run-time library.
-- jd
From: The Crossjammer
Subject: Re: Interpreters (Re: Comparing productivity: LisP against C++ (was Re: Reference Counting))
Date:
Message-ID: <XJAM.95Jan21202837@fir.CS.Berkeley.EDU>
>>>>> "Matt" == Matt Austern <····@physics7.berkeley.edu> writes:
In article <··················@physics7.berkeley.edu> ····@physics7.berkeley.edu (Matt Austern) writes:
Matt> That's not really true. Every dialect of lisp I've ever heard of
Matt> includes the function eval. Once you have eval, you have a lisp
Matt> interpreter; the top-level read-eval-print loop is just a frill.
If you count Scheme as a dialect of Lisp then there's one without eval.
However, it does have load which is just bad.
Dylan has dispensed with that, so there is a Lisp like language that does
not have to have an embeded interpreter.
--Bri
--
····@cs.Berkeley.EDU "They can't come on and play me in prime time,
Cause I know the time, cause I'm gettin' mine
Gotta have house... I get on the mix late in the night..."
From: Michael Callahan
Subject: Re: Interpreters (Re: Comparing productivity: LisP against C++ (was Re: Reference Counting))
Date:
Message-ID: <3ft6dt$s50@xmission.xmission.com>
The Crossjammer (····@fir.CS.Berkeley.EDU) wrote:
: >>>>> "Matt" == Matt Austern <····@physics7.berkeley.edu> writes:
: In article <··················@physics7.berkeley.edu> ····@physics7.berkeley.edu (Matt Austern) writes:
: Matt> That's not really true. Every dialect of lisp I've ever heard of
: Matt> includes the function eval. Once you have eval, you have a lisp
: Matt> interpreter; the top-level read-eval-print loop is just a frill.
: If you count Scheme as a dialect of Lisp then there's one without eval.
: However, it does have load which is just bad.
: Dylan has dispensed with that, so there is a Lisp like language that does
: not have to have an embeded interpreter.
EuLisp has also placed eval in the 'Language Extensions' category, it's
not part of the language. Eval is sometimes convenient to program
with, but should be discouraged from a 'Compile everything to go as
fast as possible' mentality. I've often wondered what a compiled
like C is lisp would be, if small subset evals would show up, or
if people would make Tcl, STk, and Guile interfaces for the language.
I can just imagine the confusion caused by implementing Emacs Lisp
in scheme as an extention language. Bizarre, I know, but the
dynamic nature of Emacs Lisp might be more in tune with what you
want in an extention language anyway. On the other hand, I think
it would boggle the minds of new users.
Michael Callahan
http://www.xmission.com/~callahan
From: Patrick D. Logan
Subject: Re: Interpreters (Re: Comparing productivity: LisP against C++ (was Re: Reference Counting))
Date:
Message-ID: <patrick_d_logan.94.000F9BDC@ccm.jf.intel.com>
In article <··················@fir.CS.Berkeley.EDU> ····@fir.CS.Berkeley.EDU (The Crossjammer) writes:
>If you count Scheme as a dialect of Lisp then there's one without eval.
Although it is possible to write a portable EVAL function in Scheme (See
Jaffer's SLIB source on the Scheme archive.)
And many, if not all or most, Schemes do include an EVAL-like function.
···············@ccm.jf.intel.com
Intel/Personal Conferencing Division
(503) 264-9309 FAX: (503) 263-3375
"What I envision may be impossible, but it isn't impractical."
-Wendell Berry
From: Stephen J Bevan
Subject: Re: Interpreters (Re: Comparing productivity: LisP against C++ (was Re: Reference Counting))
Date:
Message-ID: <BEVAN.95Jan27115108@lemur.cs.man.ac.uk>
In article <···························@ccm.jf.intel.com> ···············@ccm.jf.intel.com (Patrick D. Logan) writes:
>If you count Scheme as a dialect of Lisp then there's one without eval.
Although it is possible to write a portable EVAL function in Scheme (See
Jaffer's SLIB source on the Scheme archive.)
The last version of SLIB I have uses an EVAL based on LOAD which
itself is not portable (though you'll find it in many Scheme
implementations).
And many, if not all or most, Schemes do include an EVAL-like function.
Agreed, but it isn't in the standard (R4RS) though it is alledgedly in R5RS.
From: Jeff Dalton
Subject: Re: Interpreters (Re: Comparing productivity: LisP against C++ (was Re: Reference Counting))
Date:
Message-ID: <D2x6Io.9KM@cogsci.ed.ac.uk>
In article <··················@fir.CS.Berkeley.EDU> ····@fir.CS.Berkeley.EDU (The Crossjammer) writes:
>>>>>> "Matt" == Matt Austern <····@physics7.berkeley.edu> writes:
>In article <··················@physics7.berkeley.edu> ····@physics7.berkeley.edu (Matt Austern) writes:
> Matt> That's not really true. Every dialect of lisp I've ever heard of
> Matt> includes the function eval. Once you have eval, you have a lisp
> Matt> interpreter; the top-level read-eval-print loop is just a frill.
>
>If you count Scheme as a dialect of Lisp then there's one without eval.
You should count Scheme as a dialect of Lisp (except that it's
misleading to call any Lisp a dialect of Lisp). If you look at Scheme's
properties as a language, it's not very different from things that
virtually no one questions are varieties of Lisp (e.g. EuLisp level 0).
This is, moreover, a fairly mainstream view. For instance, the
_Revised^4 Report on the Algorithmic Language Scheme_ says Scheme
is a dialect of Lisp.
>However, it does have load which is just bad.
EuLisp doesn't have load or eval. Neither (so far as I can tell)
does ISLisp (the ISO WG-16 Lisp).
>Dylan has dispensed with that, so there is a Lisp like language that does
>not have to have an embeded interpreter.
Scheme does not have to have an embedded interpreter. Even Common
Lisp does not have to have an embedded interpreter.
-- jd
From: Lou Steinberg
Subject: Re: Interpreters (Re: Comparing productivity: LisP against C++ (was Re: Reference Counting))
Date:
Message-ID: <LOU.95Jan22135154@athos.rutgers.edu>
In article <··················@physics7.berkeley.edu> ····@physics7.berkeley.edu (Matt Austern) writes:
That's one reason why compiled lisp code is a bit unusual
This is completely wrong - compiled lisp code is not at all unusual.
I cannot think of any large program I have seen or heard of in LISP
for at least the last 15 years that has not been compiled once it was
debugged. The only exception to this is in systems that use LISP as
an extension / macro language. Probably the most widespread example
is GNU EMACS - but even EMACS lips compiles to a "byte-code".
On fact, some lisps (like Macintosh Common Lisp) don't even have an
interpretter - when EVAL is called, the code is compiled and the
compiled code is run.
From: Matt Austern
Subject: Re: Interpreters (Re: Comparing productivity: LisP against C++ (was Re: Reference Counting))
Date:
Message-ID: <MATT.95Jan22120400@physics7.berkeley.edu>
In article <·················@athos.rutgers.edu> ···@athos.rutgers.edu (Lou Steinberg) writes:
> In article <··················@physics7.berkeley.edu> ····@physics7.berkeley.edu (Matt Austern) writes:
>
> That's one reason why compiled lisp code is a bit unusual
>
> This is completely wrong - compiled lisp code is not at all unusual.
> I cannot think of any large program I have seen or heard of in LISP
> for at least the last 15 years that has not been compiled once it was
> debugged.
Sorry, my wording was unclear. I certainly didn't mean that lisp
compilers were rare (all but three of the lisp implementations I've
used included compilers), or that it was rare for lisp programs to be
compiled. I've used too many lisp implementations, and worked on too
many lisp projects, to have that sort of misconception.
What I meant was simply that the nature of "object" code, and of the
run-time environment for executable lisp programs, is rather different
than it is for most compiled languages. That's largely because of
eval, but there are other reasons too.
(I'm using vague wording just because it's hard to say anything that's
true of every dialect of lisp!)
--
--matt
HI, I'm writing a compiler for LISP that produces 80x86 code. I
already have it working, but would be grateful for any advice on efficiency,
or just general advice. aTdHvAaNnKcSe
bill
In article <········································@unicorn>
·······@unicorn.ccc.nottingham.ac.uk "William J Bland" writes:
> HI, I'm writing a compiler for LISP that produces 80x86 code. I
> already have it working, but would be grateful for any advice on efficiency,
> or just general advice. aTdHvAaNnKcSe
Well, I'm cheating, by writing a Scheme to C compiler (for DOS).
Good luck with your compiler. I'll be interested to try it, if
it either supports DOS, or if it supports Linux and I get Linux.
--
CommUnity: http://www.demon.co.uk/community/index.html
CommUnity: ftp://ftp.demon.co.uk/pub/archives/community
Me: http://cyber.sfgate.com/examiner/people/surfer.html
From: Jeff Dalton
Subject: Re: Interpreters (Re: Comparing productivity: LisP against C++ (was Re: Reference Counting))
Date:
Message-ID: <D2xAAC.Bu6@cogsci.ed.ac.uk>
In article <··················@physics7.berkeley.edu> ····@physics.berkeley.edu writes:
>In article <·················@athos.rutgers.edu> ···@athos.rutgers.edu (Lou Steinberg) writes:
>
>> In article <··················@physics7.berkeley.edu> ····@physics7.berkeley.edu (Matt Austern) writes:
>>
>> That's one reason why compiled lisp code is a bit unusual
>>
>> This is completely wrong - compiled lisp code is not at all unusual.
>> I cannot think of any large program I have seen or heard of in LISP
>> for at least the last 15 years that has not been compiled once it was
>> debugged.
>
>Sorry, my wording was unclear. I certainly didn't mean that lisp
>compilers were rare (all but three of the lisp implementations I've
>used included compilers), or that it was rare for lisp programs to be
>compiled. I've used too many lisp implementations, and worked on too
>many lisp projects, to have that sort of misconception.
>
>What I meant was simply that the nature of "object" code, and of the
>run-time environment for executable lisp programs, is rather different
>than it is for most compiled languages. That's largely because of
>eval, but there are other reasons too.
Such as?
And what do you think is different about the compiled code, especially
due to eval?
The main difference in compiled code is that function calls often
go through one level of indirection (e.g calling the value of a
variable rather than direct to the first instruction of the function),
that different sorts of operations might be compiled in-line
(e.g. w/o declarations addition is probably a procedure call;
OTOH, a call to mapcar is probably compiled in-line), and that
there'll be instructions in compiled Lisp code to handle tags
(in tagged pointers) or other run-time type information.
None of this is due to eval.
-- jd
From: Espen Vestre
Subject: Re: Interpreters (Re: Comparing productivity: LisP against C++ (was Re: Reference Counting))
Date:
Message-ID: <EV.95Jan23095110@viggo.telepost.no>
In article <·················@athos.rutgers.edu> ···@athos.rutgers.edu (Lou Steinberg) writes:
On fact, some lisps (like Macintosh Common Lisp) don't even have an
interpretter - when EVAL is called, the code is compiled and the
compiled code is run.
That's not quite right, you can _force_ MCL to interpret code by turning
on one or two flags. But usually you only would want to do that for
some debugging tasks, or for didactical purposes.
espen
On 21 Jan 1995, Matt Austern wrote:
> In article <·················@cfdevx1.lehman.com> ···@lehman.com (Rick Busdiecker) writes:
>
> > I think that there is a common misconceptions that Lisp is an
> > ``interpreted language''. In fact, there is nothing to prevent anyone
> > from building either a Lisp or a C++ in any of these configurations:
> > 1. Compiler and interpreter.
> > 2. Compiler with no interpreter
> > 3. Interpreter with no compiler
>
> That's not really true. Every dialect of lisp I've ever heard of
> includes the function eval. Once you have eval, you have a lisp
> interpreter; the top-level read-eval-print loop is just a frill.
>
> That's one reason why compiled lisp code is a bit unusual: the
> run-time library has to include the full interpreter.
Some Lisps run all "interpreted" stuff through the compiler, and just
tack a simple read-eval-print loop on top of things. This works OK,
unless (as I have seen) the compiler is not fully reentrant. If not,
and if (through the debugger, perhaps) you happen to reenter by the
wrong path, you lose.
From: Charles Fiterman
Subject: Re: Interpreters (Re: Comparing productivity: LisP against C++ (was Re: Reference Counting))
Date:
Message-ID: <1995Jan24.160125.6073@midway.uchicago.edu>
In article <········································@swim5.eng.sematech.org> "William D. Gooch" <······@swim5.eng.sematech.org> writes:
>On 21 Jan 1995, Matt Austern wrote:
>
>> In article <·················@cfdevx1.lehman.com> ···@lehman.com (Rick Busdiecker) writes:
>>
>> > I think that there is a common misconceptions that Lisp is an
>> > ``interpreted language''. In fact, there is nothing to prevent anyone
>> > from building either a Lisp or a C++ in any of these configurations:
>> > 1. Compiler and interpreter.
>> > 2. Compiler with no interpreter
>> > 3. Interpreter with no compiler
>>
>> That's not really true. Every dialect of lisp I've ever heard of
>> includes the function eval. Once you have eval, you have a lisp
>> interpreter; the top-level read-eval-print loop is just a frill.
>>
>> That's one reason why compiled lisp code is a bit unusual: the
>> run-time library has to include the full interpreter.
>
>Some Lisps run all "interpreted" stuff through the compiler, and just
>tack a simple read-eval-print loop on top of things. This works OK,
>unless (as I have seen) the compiler is not fully reentrant. If not,
>and if (through the debugger, perhaps) you happen to reenter by the
>wrong path, you lose.
There is a strong advantage to not having an intrepeter and a compiler.
Suppose one or the other has a bug. You really want to intrepret all
code or compile all code.
Self will optomize code that has been run more than 5 times. In compiling
you really need to say which information can be specialized out. That
is which parms etc won't change. Self specializes around types. If
you display a pig via a function that expects animals it builds a
version specialized to pigs. Most of the time the call at that point
will pass a pig to the display(animal) function. This results in
code that is competitive is speed and space to C++. Further the speed
and space characteristics of self are still improving so we can expect
this kind of strategy to pass C++ at some point.
We are experimenting with a system where the programmer decides what
to specialize on in the base language. This is hidden by higher level
constructs. An egrep written this way would read its arguments into
variables, freeze those variables telling the language these are now
constants and may be specialized around and then run. As functions
were called they would be compiled.
The self people discovered that compiled code is so much bigger than
source that it doesn't pay to cache it. That is you always compile
programs before running them. This really changes my thinking about
compilers.
From: Jeff Dalton
Subject: Re: Interpreters (Re: Comparing productivity: LisP against C++ (was Re: Reference Counting))
Date:
Message-ID: <D2z1uq.2MJ@cogsci.ed.ac.uk>
In article <·····················@midway.uchicago.edu> Charles Fiterman <···@geodesic.com> writes:
>
>There is a strong advantage to not having an intrepeter and a compiler.
>Suppose one or the other has a bug. You really want to intrepret all
>code or compile all code.
It's an advantage, but I'm not sure how strong it is. The situation
is not all that different from one in which you might use more than
one implementation or (even) different optimization / debug settings
when compiling (the -O and -g of many C compilers, for example). What
if there's a bug in one case or the other? It's something people have
been able to deal with, and an interpreter can make it easier to find
certain bugs.
-- jd
From: Henry Baker
Subject: Re: Interpreters (Re: Comparing productivity: LisP against C++ (was Re: Reference Counting))
Date:
Message-ID: <hbaker-2301950958450001@192.0.2.1>
In article <··················@physics7.berkeley.edu>,
····@physics.berkeley.edu wrote:
> In article <·················@cfdevx1.lehman.com> ···@lehman.com (Rick
Busdiecker) writes:
>
> > I think that there is a common misconceptions that Lisp is an
> > ``interpreted language''. In fact, there is nothing to prevent anyone
> > from building either a Lisp or a C++ in any of these configurations:
> > 1. Compiler and interpreter.
> > 2. Compiler with no interpreter
> > 3. Interpreter with no compiler
>
> That's not really true. Every dialect of lisp I've ever heard of
> includes the function eval. Once you have eval, you have a lisp
> interpreter; the top-level read-eval-print loop is just a frill.
>
> That's one reason why compiled lisp code is a bit unusual: the
> run-time library has to include the full interpreter.
I believe that Scheme does not require eval as a function.
In any case, a Lisp interpreter is actually quite small these days.
I think that one could write a Lisp interpreter in less room than
the space required for C's printf. (E.g., look at AutoLisp, which is
implemented in < 32K bytes for the whole system, of which the interpreter
is a relatively small portion.)
From: Tony Bass
Subject: Re: Interpreters (Re: Comparing productivity: LisP against C++ (was Re: Reference Counting))
Date:
Message-ID: <3g2i2l$5an@lamb.saltfarm.bt.co.uk>
From article <·······················@192.0.2.1>, by ······@netcom.com (Henry Baker):
> In article <··················@physics7.berkeley.edu>,
> ····@physics.berkeley.edu wrote:
>
>> In article <·················@cfdevx1.lehman.com> ···@lehman.com (Rick
> Busdiecker) writes:
>>
>> > I think that there is a common misconceptions that Lisp is an
>> > ``interpreted language''. In fact, there is nothing to prevent anyone
>> > from building either a Lisp or a C++ in any of these configurations:
>> > 1. Compiler and interpreter.
>> > 2. Compiler with no interpreter
>> > 3. Interpreter with no compiler
>>
>> That's not really true. Every dialect of lisp I've ever heard of
>> includes the function eval. Once you have eval, you have a lisp
>> interpreter; the top-level read-eval-print loop is just a frill.
eval does not not necessarily imply interpretation. I have implemented
a lisp in which eval is a compilation (to intermediate-level language)
followed by a call to execute the compiled code. This is (2) above.
It is a bit more difficult if one is compiling right down to machine
code, but certainly possible in principle.
Tony Bass
--
# Tony Bass Tel: +44 473 645305
# MLB 3/19, BT Laboratories e-mail: ···@saltfarm.bt.co.uk
# Martlesham Heath, Ipswich, Suffolk, IP5 7RE DO NOT e-mail to From: line
# Opinions are my own
From: Steve Haflich
Subject: Re: Interpreters (Re: Comparing productivity: LisP against C++ (was Re: Reference Counting))
Date:
Message-ID: <SMH.95Jan24231741@vapor.Franz.COM>
It's curious that so many respondents make vague claims that Common
Lisp EVAL can be implemented via compilation without actually showing
how it can be done. It's both succinct and instructive.
If EVAL were not present in an otherwise-conforming ANSI Common Lisp,
it could be implemented thus:
(defun eval (form)
(funcall (compile nil `(lambda () nil ,form))))
Guru wannabes might want to ponder the purpose of the last NIL. Hint:
It's purpose is _not_ to prevent a documentation string from being
taken as a form.
From: William G. Dubuque
Subject: simple EVAL implementation via COMPILE impossible? [was: Re: Interpreters (Re: Comparing productivity: LisP against C++ (was Re: Reference Counting))]
Date:
Message-ID: <WGD.95Jan25094729@martigny.ai.mit.edu>
From: ···@Franz.COM (Steve Haflich)
Date: Wed, 25 Jan 1995 07:17:41 GMT
It's curious that so many respondents make vague claims that Common
Lisp EVAL can be implemented via compilation without actually showing
how it can be done. It's both succinct and instructive.
If EVAL were not present in an otherwise-conforming ANSI Common Lisp,
it could be implemented thus:
(defun eval (form)
(funcall (compile nil `(lambda () nil ,form))))
Guru wannabes might want to ponder the purpose of the last NIL. Hint:
It's purpose is _not_ to prevent a documentation string from being
taken as a form.
Unfortunately the above simple definition of eval fails to be
correct because it does not preserve the 'compile-file' semantics
for compile-time recursive descent processing of top-level forms.
For example, consider:
(eval '(progn (defvar v1 1)
(list v1)))
In many CLtL2 implementations the 'compile' function will not
descend into the top-level lambda to process top-level forms and
hence the defvar will not have the desired top-level compile-time
side-effects.
For example, your Allegro CL/Windows illustrates this behavior.
I don't believe that Steele's CLtL2 specifies precise behavior in
this area.
Is the ANSI CL spec more precise?
-Bill
From: Patrick D. Logan
Subject: Re: Interpreters (Re: Comparing productivity: LisP against C++ (was Re: Reference Counting))
Date:
Message-ID: <patrick_d_logan.93.000F93D0@ccm.jf.intel.com>
In article <··················@physics7.berkeley.edu> ····@physics7.berkeley.edu (Matt Austern) writes:
>That's one reason why compiled lisp code is a bit unusual: the
>run-time library has to include the full interpreter.
How may times will it take to get this point across to people who post when
they don't really know?
Most commercial Lisp systems are *compilers* these days. Most of them do
interpretation by *calling the compiler*!
Even many public domain Lisps these days compile to byte codes or to C code.
Please remember this and pass it along as vigorously as you in the past have
passed along the idea that Lisp is interpreted.
···············@ccm.jf.intel.com
Intel/Personal Conferencing Division
(503) 264-9309 FAX: (503) 263-3375
"What I envision may be impossible, but it isn't impractical."
-Wendell Berry
From: Jeff Dalton
Subject: Re: Interpreters (Re: Comparing productivity: LisP against C++ (was Re: Reference Counting))
Date:
Message-ID: <D2x5Ju.8sD@cogsci.ed.ac.uk>
In article <··················@physics7.berkeley.edu> ····@physics.berkeley.edu writes:
>In article <·················@cfdevx1.lehman.com> ···@lehman.com (Rick Busdiecker) writes:
>
>> I think that there is a common misconceptions that Lisp is an
>> ``interpreted language''. In fact, there is nothing to prevent anyone
>> from building either a Lisp or a C++ in any of these configurations:
>> 1. Compiler and interpreter.
>> 2. Compiler with no interpreter
>> 3. Interpreter with no compiler
>
>That's not really true. Every dialect of lisp I've ever heard of
>includes the function eval. Once you have eval, you have a lisp
>interpreter; the top-level read-eval-print loop is just a frill.
Well, here are two that do not include eval: (1) Scheme, (2) EuLisp.
I'm pretty sure ISLisp (the Lisp being developed by ISO's WG-16)
doesn't include eval either.
>That's one reason why compiled lisp code is a bit unusual: the
>run-time library has to include the full interpreter.
Why would that make *compiled code* unusual?
In any case, (1) the full interpreter can be rather small, and (2)
no actual interpreter is needed (e.g. PopLog Common Lisp's eval
uses the compler -- the is no interpreter).
-- jd
From: Patrick Tufts
Subject: Re: Interpreters (Re: Comparing productivity: LisP against C++ (was Re: Reference Counting))
Date:
Message-ID: <3g64ht$apo@news.cs.brandeis.edu>
····@physics7.berkeley.edu (Matt Austern) writes:
>In article <·················@cfdevx1.lehman.com> ···@lehman.com (Rick Busdiecker) writes:
>> I think that there is a common misconceptions that Lisp is an
>> ``interpreted language''. In fact, there is nothing to prevent anyone
>> from building either a Lisp or a C++ in any of these configurations:
>> 1. Compiler and interpreter.
>> 2. Compiler with no interpreter
>> 3. Interpreter with no compiler
>That's not really true. Every dialect of lisp I've ever heard of
>includes the function eval. Once you have eval, you have a lisp
>interpreter; the top-level read-eval-print loop is just a frill.
Jeffrey Siskind's "stalin" is a compile-only system that generates
stand-alone object code.
There are probably others that don't have eval.
--Pat