Lisp is not an interpreted language
Ralph Silverman
Carl L. Gay (cg...@ix.cs.uoregon.edu) wrote:
: From: thomas hennes <aie...@pobox.oleane.com>
: Date: Sat, 19 Oct 1996 03:48:28 +0100
: Well, i am not sure about this. Consider the case of software agents
: --which is directly linked to AI if you bear in mind that GOOD agents
: are genetically evolutive (ideally). When dealing with networked agents,
: you just cannot let pointer arithmetic (an automatic feature of C/C++)
: get into the way, for obvious security reasons. LISP, on the other hand,
: is one language that manages this pretty well, as do others such as
: SafeTCL (another interpreted language!!).
: Another?
: What i actually believe is that interpreted languages and compiled
: languages have very different application domains. Interpreted languages
: work wonders when used as tiny specialized scripts.
: No, Common Lisp is not an interpreted language.
: Yes, Lisp interpreters exist.
: All commercial Common Lisps that I'm aware of are compiled by default.
: Even if you type in a "tiny specialized script" it is usually compiled
: before it is executed.
: Harumph. :)
--
***************begin r.s. response***************
lisp
is one of the earliest
high level languages,
dating to the 1950s...
certainly,
in early implementations,
lisp
was available primarily
as an interpreted language...
historically, lisp pioneered
routine availability of
recursion
to the programmer...
later...
so generally available in
the widespread tradition dating
to algol60(revised)...
for those with systems capable
of supporting (ms dr pc)dos
(286 good)...
versions of lisp interpreters
are freely available as shareware...
(lisp like)
xlisp
and
pc-lisp;
each of these is remarkable
and very well made...
(xlisp is available in a
variety of releases...)
***************end r.s. response*****************
Ralph Silverman
z007...@bcfreenet.seflin.lib.fl.us
Ralph Silverman
Ralph Silverman (z007...@bcfreenet.seflin.lib.fl.us) wrote:
: : Another?
: : Yes, Lisp interpreters exist.
: : Harumph. :)
: --
: ***************begin r.s. response***************
--
******************begin r.s. response******************
during the time of the early
development of
lisp
,
limitations,
now virtually taken for granted,
were not necessarily accepted...
self-modification of software
particularly,
was thought, by some,
to be a design goal for
advanced computer
programming languages...
in early, interpreted forms,
lisp
supported such use...
various aspects of
self-modification were programmed
into systems...
******************end r.s. response********************
Ralph Silverman
z007...@bcfreenet.seflin.lib.fl.us
Ben Sauvin
Ralph, please forgive me (this is NOT a flame), but I GOTTA know: what
text formatting language or utility are you using? :)
Ralph Silverman
Liam Healy (Liam....@nrl.navy.mil) wrote:
: cg...@ix.cs.uoregon.edu (Carl L. Gay) writes:
: >
: >
: > From: thomas hennes <aie...@pobox.oleane.com>
: > Date: Sat, 19 Oct 1996 03:48:28 +0100
: >
: > Well, i am not sure about this. Consider the case of software agents
: > --which is directly linked to AI if you bear in mind that GOOD agents
: > are genetically evolutive (ideally). When dealing with networked agents,
: > you just cannot let pointer arithmetic (an automatic feature of C/C++)
: > get into the way, for obvious security reasons. LISP, on the other hand,
: > is one language that manages this pretty well, as do others such as
: > SafeTCL (another interpreted language!!).
: >
: > Another?
: >
: > What i actually believe is that interpreted languages and compiled
: > languages have very different application domains. Interpreted languages
: > work wonders when used as tiny specialized scripts.
: >
: > No, Common Lisp is not an interpreted language.
: >
: > Yes, Lisp interpreters exist.
: >
: > All commercial Common Lisps that I'm aware of are compiled by default.
: > Even if you type in a "tiny specialized script" it is usually compiled
: > before it is executed.
: >
: > Harumph. :)
: This is not the first time this assumption about LISP has been made.
: I think many people make the mistaken assumption that LISP is
: interpreted because it's interactive and dynamically linked, and
: confuse the two concepts. They look at the "batch"
: (edit-compile-link-run) model of conventional languages like C or
: Fortran and identify that with compilation. After all, what language
: other than LISP is interactive and compiled? (Forth is the only one I
: can think of.)
: All the more reason that LISP is an essential component of a
: programming education.
: --
: Liam Healy
: Liam....@nrl.navy.mil
--
***************begin r.s. response********************
i guess a
'dynamic compiler'
for a language is a fancy
kind of interpreter...
whatever the name sounds like;
yes???
after all,
when a program actually has been
compiled and linked
successfully,
it runs from binary ...
NOT A SCRIPT!!!!!!!!!!!!!!!!!!!!!!!!!!
^^^^^^^^^^^^
(a program compiled and linked
properly is not, routinely,
recompiled at
runtime
...
a program requiring
anything like that
^^^^^^^^^^^^^^^^^^
^^^^^^^^^^^^^^^^^^
is interpreted!!!
)
***************end r.s. response**********************
Ralph Silverman
z007...@bcfreenet.seflin.lib.fl.us
Mark
Ralph Silverman <<z007...@bcfreenet.seflin.lib.fl.us>> wrote:
<CUT talk of LISP>
What about object code that is relocatable? Is that
interpreted? It sure ain't straight block load binary
to fixed address and jmp...
what about such as TAOS? Single object code loadable
onto mulitple heterogenous processors, with translation
taking place at loadtime? i.e. single object translated
on demand for specific processor? By your above logic
interpreted.
What about Intel code running on an alpha? Is that
interpreted? or compiled? It was compiled with regard
to an intel, but is now acting (to some extent) as
instructions for an interpreter.... by your above logic
an existance os both compiled and interpreted....
Hmmm
Andrew Gierth
WATCH THOSE NEWSGROUPS LINES!!!
This thread is now in:
comp.ai
comp.ai.genetic
comp.ai.neural-nets
comp.lang.lisp
comp.lang.c++
comp.os.msdos.programmer
comp.lang.asm.x86
comp.unix.programmer
comp.ai.philosophy
When following up, exclude as many of these as possible.
It seems Mr. Silverman is up to his tricks again.
--
Andrew Gierth (and...@microlise.co.uk)
"Ceterum censeo Microsoftam delendam esse" - Alain Knaff in nanam
Cyber Surfer
In article <54nr3t$d...@nntp.seflin.lib.fl.us>
z007...@bcfreenet.seflin.lib.fl.us "Ralph Silverman" writes:
> i guess a
> 'dynamic compiler'
> for a language is a fancy
> kind of interpreter...
> whatever the name sounds like;
> yes???
No. You might like to read 'Writing Interactive Compiler and
Interpreters'. Alternately, take a look at any Forth 'interpreter,
and you'll find that there's a _compiler_. The 'interpreter'
is the address interpreter, but in some Forths, the object code
will be native code. Not that you'll often need to know this!
Forth does an excellent job of hiding such details, and revealing
them when you need them.
In that sense, Lisp is very similar. So are many Basic 'interpreters'.
> after all,
> when a program actually has been
> compiled and linked
> successfully,
> it runs from binary ...
> NOT A SCRIPT!!!!!!!!!!!!!!!!!!!!!!!!!!
> ^^^^^^^^^^^^
Not necessarily. Concepts like 'compiling' come from certain
language implementations, and their (batch) enviroments.
There are also C interpreters, but few people call C an
interpreterd language. Some Pascal and C compilers are so fast
that you barely see them running, and there are incremental
compilers for Lisp and other languages, too. There are even
a few incremental C/C++ compilers!
'Linking' is another idea that's tied to 'batch' enviroments.
I find it sad that so called 'visual' enviroments perpetuate
such archaic practices. They're so common that some people,
like yourself, mistake them for the _only_ way to compile.
> (a program compiled and linked
> properly is not, routinely,
> recompiled at
> runtime
> ...
> a program requiring
> anything like that
> ^^^^^^^^^^^^^^^^^^
> ^^^^^^^^^^^^^^^^^^
> is interpreted!!!
> )
This is only because of a great deal of stagnation amoung
compilers for languages like Pascal, C/C++, etc. In case
you've not noticed this, Java is changing this. JIT is just
another name for what PJ Brown called a "throw away compiler".
Tao Systems have used this technique in an _operating system_.
Wake up and smell the coffee (pun intended). Anyway, it'll
get much harder for you to resist pretty soon, coz you'll find
that software using such compiler tech will be available to
_you_, on your machine (whatever that is). If not, then your
opinions will be irrelevant, assuming that they not already,
as there's already too much interest to stop it from happening.
I don't like to use the 'inevitable' to describe technology,
but I might compare it to a steamroller. ;-) I've been using
this kind of compiler for years, so it's rather satisfying to
see 'mainstream' developers discovering it too. At last we can
move on! Hurrah! It'll be very hard to deny it works when so
many people are using it.
Please forgive me if I sound a little smug...
--
<URL:http://www.enrapture.com/cybes/> You can never browse enough
Future generations are relying on us
It's a world we've made - Incubus
We're living on a knife edge, looking for the ground -- Hawkwind
Cyber Surfer
In article <Dzt9M...@world.std.com> d...@world.std.com "Jeff DelPapa" writes:
> Hell, there are some machine codes that qualify under that metric. If
> the machine uses some sort of microcode, the "native" machine code
> counts as interpreted. (also there are a small number of C systems
> that have limited incremental compilation. (if nothing else the ones
> for lispm's could do this.) -- One of the lispm vendors even had a
> dynamically compiling FORTRAN)
Let's not forget the interpreter that is _very_ popular with C
programmers: printf. Common Lisp programmers have format, which
kicks printf's butt, but at a price. Not everyone wants to print
a number in Roman numerals, and those that do might be happy with
some library code. Still, dynamic linking can handle that...
It seems to me that Lisp programmers can be more ambitions, in
that they reach for higher goals. I've not yet had a chance to
compare MFC with Garnet, but I suspect that it might be an unfair
comparison. Which tool looks "better" may depend on what you wish
to do, and how well it helps you accomplish it.
My own experience is that when I use Lisp, I consider techniques
that I dismiss as "too expensive" when I use C++. The truth is that
it just looks like too much work in C++! While you look at small
programming examples, it may seem that Lisp's advantages are small.
When you multiply the size of the code by several orders of magnitude,
Lisp begins to make a very significant difference, not only to the
amount of time to develop something, but in many other ways, too.
Unfortunately, if you've never experienced this yourself, you might
find it hard to believe.
I'm still impressed by it today. I keep thinking, "This shouldn't
be this easy, or should it?" Well, yes it should! It's the pain of
using C++ that fools me into thinking that some things are just
inherently difficult. If I think too much about how I'd do something
in Lisp, when that option isn't available to me (yes, it is possible
for that to happen), I get seriously frustrated.
Imagine that the only forms of control flow available in C were
'if' and 'goto', or if you didn't have 'struct' and 'typedef'.
That isn't even close to how ANSI C or C++ look to me, compared
to Lisp. Of course, I might be just as happy with ML, as Lisp's
syntax and relaxed attitude to type declarations isn't really
what attracts me to the language. I just discovered Lisp earlier.
Jeff Dalton
>: > All commercial Common Lisps that I'm aware of are compiled by default.
>: > Even if you type in a "tiny specialized script" it is usually compiled
>: > before it is executed.
Humm. I've used a fair number of Common Lisps (mostly commercial
ones) that don't work that way. They have an interpreter as well
as a compiler, and interpretation is the default. However, most
Common Lisp implementations have a compiler that compiles to native
code and that can compile source files to object files -- and that
should be compiler-like enough to satisfy almost everyone. ^_^
In any case, Lisp is not an interpreted or compiled _language_.
_Implementations_ of Lisp might be interpreters or compilers or
some combination.
-- jd
Richard A. O'Keefe
>In article <54nr3t$d...@nntp.seflin.lib.fl.us>,
>Ralph Silverman <z007...@bcfreenet.seflin.lib.fl.us> wrote:
>> after all,
>> when a program actually has been
>> compiled and linked
>> successfully,
>> it runs from binary ...
>> NOT A SCRIPT!!!!!!!!!!!!!!!!!!!!!!!!!!
>> ^^^^^^^^^^^^
This view is so far out of date that it wasn't even true in the SIXTIES.
I'll mention two examples from the 70s. Both of them apply to the B6700,
a machine which was so compiler-oriented that
- it didn't have an assembler. Period. NONE. There were about 20
instructions in the (very capable for its time) operating system that
weren't generated by the ESPOL compiler, and they were hand translated
binary stuck in an array.
- the average Joe program couldn't be a compiler either; object files
had an "is-a-compiler" bit which could only be set by an operator
in the control room "blessing" the program.
Example 1. Student Fortran compiler.
The Auckland University "STUFOR" compiler was an Algol program that
read student Fortran programs, generated *native* code for them,
and called that native code.
(The original student Pascal compiler for the CDC machines did
much the same thing. Pascal, remember, is a 60s language. Wirth
reported that compiling to native code directly and jumping to it
was significantly faster than using the operating system's native
linker.)
Example 2. The REDUCE symbolic algebra system.
REDUCE is written in a Lisp dialect called PSL.
When typing at the PSL system, you could ask it to compile
a file. It did this by
reading the file,
generating _Algol_ source code,
calling the Algol compiler to generate native code.
Since the B6700 operating system let code in one object file
*dynamically* call code from another object file, problem solved.
Now just think about things like
- VCODE (a package for dynamically generating native code; you specify
the code in a sort of abstract RISC and native code is generated for
SPARC, MIPS, or something else I've forgotten -- I have VCODE and a
SPARC but not the other machines it supports).
- dynamic linking, present in UNIX System V Release 4, Win32, OS/2, VMS,
...
Run-time native code generation has been used in a lot of interactive
programming languages including BASIC (for which "throw-away compiling"
was invented), Lisp, Pop, Smalltalk, Self, Prolog, ML, Oberon, ...
The original SNOBOL implementation compiled to threaded code, but SPITBOL
compiled to native code dynamically.
The B6700 is in fact the only computer I've ever had my hands on where
dynamic code generation was difficult. (Ok, so flushing the relevant
part of the I-cache is a nuisance, but it is _only_ a nuisance.)
Oh yes, the punchline is this: on the B6700, "scripts" in their job
control language (called the WorkFlow Language, WFL) were in fact
*compiled*, so just because something is a script, doesn't mean it
can't be or isn't compiled.
--
Mixed Member Proportional---a *great* way to vote!
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.
Chris
Richard A. O'Keefe <o...@goanna.cs.rmit.edu.au> a écrit dans l'article
<554cdn$ncb$1...@goanna.cs.rmit.edu.au>...
> >In article <54nr3t$d...@nntp.seflin.lib.fl.us>,
> >Ralph Silverman <z007...@bcfreenet.seflin.lib.fl.us> wrote:
> >> after all,
> >> when a program actually has been
> >> compiled and linked
> >> successfully,
> >> it runs from binary ...
> >> NOT A SCRIPT!!!!!!!!!!!!!!!!!!!!!!!!!!
> >> ^^^^^^^^^^^^
>
I belieave Compiling means translate from a language to another. Not have
to translate in native binary code.
Chris
Bull Horse
PASCAL is a 70's langauage. Developed in the early 70's I think 73...
Bull Horse
Chris wrote:
> =
> Richard A. O'Keefe <o...@goanna.cs.rmit.edu.au> a =E9crit dans l'article
> <554cdn$ncb$1...@goanna.cs.rmit.edu.au>...
> > >In article <54nr3t$d...@nntp.seflin.lib.fl.us>,
> > >Ralph Silverman <z007...@bcfreenet.seflin.lib.fl.us> wrote:
> > >> after all,
> > >> when a program actually has been
> > >> compiled and linked
> > >> successfully,
> > >> it runs from binary ...
> > >> NOT A SCRIPT!!!!!!!!!!!!!!!!!!!!!!!!!!
> > >> ^^^^^^^^^^^^
> >
> =
> I belieave Compiling means translate from a language to another. Not have=
> to translate in native binary code.
> =
> Chris
Uh I think that Compiling means to translate anything into machine code. =
Interpreted means to identify a string value with an according machine =
code instruction.
scha...@wat.hookup.net
In <327B42...@earthlink.net>, Bull Horse <s...@earthlink.net> writes:
>PASCAL is a 70's langauage. Developed in the early 70's I think 73...
Definitely much earlier. It must have been 68 or 69
Hartmann Schhaffer
Chris
>Uh I think that Compiling means to translate anything into machine code.
----------
I don't think so. The compiler usually translate to assembly, then the
assembler translates to machine code. Sometimes the assembler is built in,
sometimes it may translate in one pass.
What about the Java compiler ? Is the code in machine language ? Isn't it a
compiler ?
Chris
Cyber Surfer
In article <327D00...@earthlink.net> s...@earthlink.net "Bull Horse" writes:
> Uh I think that Compiling means to translate anything into machine code. =
>
> Interpreted means to identify a string value with an according machine =
>
> code instruction.
I'd use a more general definition, and say that "compiling" is
when you translate from one form into another. It might not even
be a one-way translation. I recall reading that QuickBasic code
exists in one of 3 different forms, depending on the state of the
"interpreter" (running, editing, and a 3rd state).
If we want to, we can imagine that a typical compiler will translate
one string (e.g. source code) into another (e.g. machine code). Not
all compiles use strings, however. Compiler theory is just a special
case for strings! We can even represent trees and other data structures
as strings. The reverse is also possible.
Isn't this fun?
Mike McDonald
In article <01bbca97$15522cc0$LocalHost@gaijin>,
"Chris" <gai...@infonie.fr> writes:
>>Uh I think that Compiling means to translate anything into machine code.
> ----------
> I don't think so. The compiler usually translate to assembly, then the
> assembler translates to machine code. Sometimes the assembler is built in,
> sometimes it may translate in one pass.
>
> What about the Java compiler ? Is the code in machine language ? Isn't it a
> compiler ?
>
> Chris
Trying to distinguish between "compiled" and "interpreted" seems
like a complete waste of time, to me anyway. Afterall, everything is
interpreted eventually anyway. That's what a CPU is, afterall. Just
another interpreter.
Mike McDonald
mik...@engr.sgi.com
Mark
Chris wrote:
>
> >Uh I think that Compiling means to translate anything into machine code.
> >Interpreted means to identify a string value with an according machine
> >code instruction.
> ----------
> I don't think so. The compiler usually translate to assembly, then
> the assembler translates to machine code. Sometimes the assembler is
> built in, sometimes it may translate in one pass.
> What about the Java compiler ? Is the code in machine language ?
> Isn't it a compiler ?
The compiler doesn't necessarily translate to assembly; the ones
that do are multipass compilers. Single pass compilers translate
source code directly to object code.
Java compiles to a bytecode; this is either: interpreted by a program
acting as a virtual processor, or is the instruction set of a real
processor. In both senses the bytecode has been compiled. In only
one sense is the code strictly in machine language. The Java virtual
machine is an interpreter; it is executing idealised machine code.
Norman L. DeForest
[ newsgroups trimmed ]
Chris (gai...@infonie.fr) wrote:
: >Uh I think that Compiling means to translate anything into machine code.
: >Interpreted means to identify a string value with an according machine
: >code instruction.
: ----------
: I don't think so. The compiler usually translate to assembly, then the
: assembler translates to machine code. Sometimes the assembler is built in,
: sometimes it may translate in one pass.
: What about the Java compiler ? Is the code in machine language ? Isn't it a
: compiler ?
: Chris
You can compile to machine code, you can compile to a series of links
in a linked list (some implementations of Forth), or you can compile to
an intermediate pseudo-code that is interpreted at run time (GW-BASIC or
at least one version of Pascal (USCD Pascal if I'm not wrong)).
Norman De Forest
af...@chebucto.ns.ca
http://www.chebucto.ns.ca/~af380/Profile.html
.........................................................................
Q. Which is the greater problem in the world today, ignorance or apathy?
A. I don't know and I couldn't care less.
.........................................................................
For those robots that gather e-mail addresses from postings and sig. blocks:
Junk e-mail received so far this month from:
west...@leonardo.net and inv...@onlinenow.net and act...@icanect.net and
pat...@netsoft.ie and j...@mymail.com and in...@uar.com
--
Cyber Surfer
In article <55m3kt$1...@fido.asd.sgi.com>
mik...@engr.sgi.com "Mike McDonald" writes:
> Trying to distinguish between "compiled" and "interpreted" seems
> like a complete waste of time, to me anyway. Afterall, everything is
> interpreted eventually anyway. That's what a CPU is, afterall. Just
> another interpreter.
Books have been written about this. My favourite is "Writing
Interactive Compilers and Interpreters", P.J. Brown, ISBN 0
471 27609 X, ISBN 0471 100722 pbk. John Wiley & Sons Ltd,
but it isn't unique. For example, there's "Structure and
Interpretation of Computer Programs, Second Edition, by Harold
Abelson and Gerald Jay Sussman with Julie Sussman.
Dan Mercer
Bull Horse (s...@earthlink.net) wrote:
: Chris wrote:
: > =
: > Richard A. O'Keefe <o...@goanna.cs.rmit.edu.au> a =E9crit dans l'article
: > <554cdn$ncb$1...@goanna.cs.rmit.edu.au>...
: > > >In article <54nr3t$d...@nntp.seflin.lib.fl.us>,
: > > >Ralph Silverman <z007...@bcfreenet.seflin.lib.fl.us> wrote:
: > > >> after all,
: > > >> when a program actually has been
: > > >> compiled and linked
: > > >> successfully,
: > > >> it runs from binary ...
: > > >> NOT A SCRIPT!!!!!!!!!!!!!!!!!!!!!!!!!!
: > > >> ^^^^^^^^^^^^
: > >
: > =
: > I belieave Compiling means translate from a language to another. Not have=
: > to translate in native binary code.
: > =
: > Chris
: Uh I think that Compiling means to translate anything into machine code. =
: Interpreted means to identify a string value with an according machine =
: code instruction.
Then what does YACC stand for? (Yet Another Compiler-Compiler). Lex, yacc,
and cfront all compile input into C-src code, which must be further
compiled into machine code.
--
Dan Mercer
Reply To: dame...@mmm.com
Mukesh Prasad
"Compiled" vs "Interpreted" are merely words -- if
any programming language which can be compiled into a byte-code
is to be called a "compiled" language, we should drop altogether
the concept of an "interpreted" language, since for
any given programming language, a byte-code and a byte-code
compiler can be found.
But if one has to have this distinction, Lisp should
fall into the "interpreted" category, since the
"compiled" byte-code is interpreted by sofware, not
the hardware. I don't know about the Lisp
machines though, do they (or did they) have hardware
instructions corresponding one-to-one with read/eval/print?
Rainer Joswig
In article <3280FE...@dma.isg.mot.com>, Mukesh Prasad
<mpr...@dma.isg.mot.com> wrote:
> "Compiled" vs "Interpreted" are merely words -- if
> any programming language which can be compiled into a byte-code
> is to be called a "compiled" language, we should drop altogether
> the concept of an "interpreted" language, since for
> any given programming language, a byte-code and a byte-code
> compiler can be found.
Ahh, you guys you still don't get it.
A compiler-based system ->
Language A compiles to Language B.
How languge B runs (native, as byte code, ...) is not
of any importance. Important is that Language A gets
compiled into a target language (b).
An Interpreter-based system ->
Language A is being read by an Interpreter.
This results in some internal representation
for programs of the language A.
This internal representation then is being interpreted.
The internal representation is a direct mapping
from the original source.
To give you an example:
A Lisp compiler takes expression in the Lisp
language and compiles it for example to PowerPC
machine code. The PowerPC processor then executes
this machine code. This is a compiler-based system
(like Macintosh Common Lisp).
A Lisp compiler takes expression in the Lisp
language and compiles it to Ivory (!!)
instructions. The Ivory code is than
being interpreted by a virtual machine running
on a DEC Alpha processor.
This is still a compiler-based system
(like Open Genera from Symbolics).
A Lisp Interpreter takes expressions in
the Lisp language, interns them and
executes these interned representation
of the program. Still, every statement
has to be examined (is it a macro,
is it a function call, is it a constant, ...).
Still, macro expansion
will happen for every loop cycle over and
over. You can get the original expression back
and change it, because there is a one to
one relation between the original source
and the interned representation.
> But if one has to have this distinction, Lisp should
> fall into the "interpreted" category, since the
> "compiled" byte-code is interpreted by sofware, not
> the hardware.
Ahh, no.
There are also tons of compilers who generate optimized
machine code of CISC and RISC architectures.
>I don't know about the Lisp
> machines though, do they (or did they) have hardware
> instructions corresponding one-to-one with read/eval/print?
Sure not.
Read a basic computer science book, where they explain the
difference (get: Structure and Interpretation of
Computer Programs, by Abelson & Sussman, MIT Press).
Rainer Joswig
Patrick Juola
In article <3280FE...@dma.isg.mot.com> Mukesh Prasad <mpr...@dma.isg.mot.com> writes:
>"Compiled" vs "Interpreted" are merely words -- if
>any programming language which can be compiled into a byte-code
>is to be called a "compiled" language, we should drop altogether
>the concept of an "interpreted" language, since for
>any given programming language, a byte-code and a byte-code
>compiler can be found.
>
>fall into the "interpreted" category, since the
>"compiled" byte-code is interpreted by sofware, not
>machines though, do they (or did they) have hardware
>instructions corresponding one-to-one with read/eval/print?
You're palming a card. C, a compiled language by anyone's reckoning,
has no (single) hardware instruction corresponding to printf. Or even
necessarily to ||, because of the complex semantics of evaluation.
As a matter of fact, many of us consider a language that *does*
correspond 1-1 with a set of hardware instructions to be an
assembly language.... and the advantage of "compiled" languages
is that they let one get *away* from this level of detail.
Patrick
Ken Bibb
>"Compiled" vs "Interpreted" are merely words -- if
>any programming language which can be compiled into a byte-code
>is to be called a "compiled" language, we should drop altogether
>the concept of an "interpreted" language, since for
>any given programming language, a byte-code and a byte-code
>compiler can be found.
>But if one has to have this distinction, Lisp should
>fall into the "interpreted" category, since the
>"compiled" byte-code is interpreted by sofware, not
>the hardware.
This is not necessarily the case. Most modern lisps allow you to create
binary executables.
--
Ken Bibb "If the boundary breaks I'm no longer alone
kb...@arastar.com Don't discourage me
kb...@best.com Bring out the stars/On the first day"
kb...@csd.sgi.com David Sylvian--"The First Day"
Seth Tisue
>fall into the "interpreted" category, since the
>"compiled" byte-code is interpreted by sofware, not
>the hardware.
There are many Lisp compilers which compile to native code, not byte
code. (It seems that many have been pointing this out on this thread
for some time, to no avail...)
--
== Seth Tisue <s-t...@nwu.edu> http://www.cs.nwu.edu/~tisue/
Jim Balter
In article <55t27r$d...@godzilla.cs.nwu.edu>,
Seth Tisue <ti...@cs.nwu.edu> wrote:
>In article <3280FE...@dma.isg.mot.com>,
>Mukesh Prasad <mpr...@dma.isg.mot.com> wrote:
>>But if one has to have this distinction, Lisp should
>>fall into the "interpreted" category, since the
>>"compiled" byte-code is interpreted by sofware, not
>>the hardware.
>
>There are many Lisp compilers which compile to native code, not byte
>code. (It seems that many have been pointing this out on this thread
>for some time, to no avail...)
Ignorance memes are highly resistant and mutate readily.
--
<J Q B>
Dave Seaman
In article <55t27r$d...@Godzilla.cs.nwu.edu>,
Seth Tisue <ti...@cs.nwu.edu> wrote:
>In article <3280FE...@dma.isg.mot.com>,
>Mukesh Prasad <mpr...@dma.isg.mot.com> wrote:
>>But if one has to have this distinction, Lisp should
>>fall into the "interpreted" category, since the
>>"compiled" byte-code is interpreted by sofware, not
>>the hardware.
>
>There are many Lisp compilers which compile to native code, not byte
>code. (It seems that many have been pointing this out on this thread
>for some time, to no avail...)
Not only that, many modern lisps use incremental compilation. A good
test is to use DEFUN to define a function and then immediately use
SYMBOL-FUNCTION to look a the definition of that function. If you are
using an interpreted lisp, you will see the lambda expression that you
specified with DEFUN, but if your lisp has incremental compilation
(such as Macintosh Common Lisp) you will instead see only that the
value is a compiled function. On systems that are not incrementally
compiled, you can probably still use (COMPILE 'FOO) in order to compile
an individual function, which may be confirmed by again using
(SYMBOL-FUNCTION 'FOO) to view the function definition.
If you want more proof that some lisps are truly compiled, consider the
fact that Macintosh Common Lisp has separate versions for the PowerPC
and for 68K Macs. The 68K version will run on either type of machine
(using the system's 68K interpreter when running on the PowerPC), but
the PowerPC version will not run on a 68K machine at all (because it's
native PowerPC code and it won't run on 68K Macs). The same goes for
compiled files and saved applications that you can produce with the two
versions.
If you compile a lisp file (foo.lisp) with MCL 3.0 (the 68K version),
you get a fast-loading file (foo.fasl) that contains native 68K code.
If you compile the same file using MCL 3.9PPC, you get a file foo.pfsl
that contains native PowerPC code and is not usable on a 68K Mac. If
you use SAVE-APPLICATION to produce a double-clickable application
program, the resulting program will not run on a 68K Mac if it was
produced by the PowerPC version of MCL.
If programs were being "compiled" to byte-code, there obviously would
be no need for all this -- just re-implement the byte-code interpreter
on the PowerPC.
--
Dave Seaman dse...@purdue.edu
++++ stop the execution of Mumia Abu-Jamal ++++
++++ if you agree copy these lines to your sig ++++
++++ see http://www.xs4all.nl/~tank/spg-l/sigaction.htm ++++
Richard A. O'Keefe
Mukesh Prasad <mpr...@dma.isg.mot.com> writes:
>"Compiled" vs "Interpreted" are merely words
So? Are you claiming Humpty Dumpty's privilege?
There are important issues concerning binding time.
>But if one has to have this distinction, Lisp should
>fall into the "interpreted" category, since the
>"compiled" byte-code is interpreted by sofware, not
>the hardware.
This is complete and utter bull-dust.
The RUCI Lisp system I used on a DEC-10 in the early 80s compiled
Lisp to *native* DEC-10 instructions.
The Franz Lisp system I used on a VAX-11/780 around the same time
compiled Lisp to *native* VAX instructions.
The Gmabit Scheme system I use on a 680x0 Macintosh compiles
Scheme (a dialect of Lisp) to *native* 680x0 instructions.
The Lisp system I use on a a SPARC compiles Common Lisp
to *native* SPARC instructions.
Even the PSL system I used on a B6700 back in the 70s compiled
PSL (a dialect of Lisp) to *native* B6700 instructions.
The T system I used to use on our Encore Multimaxes compiled
T and Scheme (dialects of Lisp) to *native* NS32k instructions.
There are or have been *native-code* Lisp compilers for all the
major machines, from Univac 1108s, IBM 360s, all the way up to
Connection Machines and beyond.
>I don't know about the Lisp
>machines though, do they (or did they) have hardware
>instructions corresponding one-to-one with read/eval/print?
Why Lisp machines do you mean? CONS? CADR? LMI? Symbolics?
Xerox (1108, 1109, 1185, ...)? The Japanese ones? The European ones?
The plain fact of the matters is that Lisp
- *CAN* be interpreted by fairly simple interpreters
- *CAN* be compiled to very efficient native code on any reasonable
modern machine
[If you can compile a language to byte codes, you can compile it to
native code by treating the byte codes as "macros", and running an
optimiser over the result. This has actually been used as a route
for developing a native code compiler.]
Mukesh Prasad
Jim Balter wrote:
> In article <55t27r$d...@godzilla.cs.nwu.edu>,
> Seth Tisue <ti...@cs.nwu.edu> wrote:
[...]
> >There are many Lisp compilers which compile to native code, not byte
> >code. (It seems that many have been pointing this out on this thread
> >for some time, to no avail...)
Ah, "compiling to native code" brings up a different issue,
that of whether or not you want to allow eval in the
language. If you do, there are some sleigh of hands
involved (like hiding an interpreter in your "compiled"
executable.) If you don't, is it Lisp? Why not
make a new language with just the features you
like and _can_ compile well?
The point was, if you claim Lisp is "Compiled" and not
"Interpreted", show me an "Interpreted" language, and
I will use your arguments to show why it should
be called "compiled" (because compilers can be written
to compile selected parts of the language to
native code.) So what is the point of such
a distinction?
> Ignorance memes are highly resistant and mutate readily.
How true!
David Longley
Interesting....
ENGLISH is a 90s language, and an 80s language, and a ....... and
ANSI has never had a say in it.
I have long wondered why folk in Natural Language processing
research bother...Have they ever read "Word and Object"? Do they
realise the implications of it being an anarchic, evolving, yet
ANSI free system?
--
David Longley
Cyber Surfer
In article <joswig-ya0231800...@news.lavielle.com>
jos...@lavielle.com "Rainer Joswig" writes:
> Read a basic computer science book, where they explain the
> difference (get: Structure and Interpretation of
> Computer Programs, by Abelson & Sussman, MIT Press).
Or an even more basic book, like PJ Brown's "Writing Interactive
Compilers and Interpreters". Brown also covers reconstructing
the source code from the internal representation. In his book,
he uses the Basic language for his examples, but the _same_
techniques can apply to Lisp and any other language. In the
case of Lisp, most implementations will actually store the
internal representation, instead of throwing it away, as most
"compilers" do.
Brown uses the word "compiler" to mean either interpreter or
compiler, because few - if any - implementations are "true"
compilers or interpreters, as that would be impractical. For
example, the C language uses a runtime - violating the "true
compiler" defintion - and functions like printf very small
interpreters. There are even C interpreters available, so
is C compiled or interpreted? The correct answer is that it
can be either, and all C implementations include a mixture
of both compiling (at compile time) _and_ interpreting (at
runtime and also compile time).
Compiler theory is a weird and wonderful area of computer
science, but some people can explain it in relatively clear
and simple terms. Brown is one of those people. If you can
cope with that book, then you _might_ be reader to take a
book like "Structure and Interpretation of Computer Programs".
Brown's book is in fact a book about any writing interactive
software, not just compilers. SICP is a much more demanding
book, and as the intro explains, the material can form the
basis of several programming courses! A fine book, but if
you're likely to get into MIT, then it's perhaps not the best
place to start.
Apart from that, I fully agree with what you say about compilers
and interpreters. I like to think of them both as specialised
examples of string and symbol crunching: turn a string into a
tree, and then turn the tree back into a string, only this time
in a different language. A simple example would be date parsing,
where you parse a date in one format and then print it in another.
Bruce Tobin
Mukesh Prasad wrote:
>
> Ah, "compiling to native code" brings up a different issue,
> that of whether or not you want to allow eval in the
> language. If you do, there are some sleigh of hands
> involved (like hiding an interpreter in your "compiled"
> executable.) If you don't, is it Lisp?
Of course it's Lisp. Most modern Lisp texts strongly discourage the use
of eval for just this reason. I've never written a line of code with
eval in it.
> Why not
> make a new language with just the features you
> like and _can_ compile well?
>
> The point was, if you claim Lisp is "Compiled" and not
> "Interpreted", show me an "Interpreted" language, and
> I will use your arguments to show why it should
> be called "compiled" (because compilers can be written
> to compile selected parts of the language to
> native code.) So what is the point of such
> a distinction?
>
A language can be called "interpreted", in a non-technical but widely
used sense, when the implementations most commonly used for production
applications fail to compile to native code. The Basic dialect used in
Visual Basic, for example, fits this criterion (though it may not for
much longer); Lisp doesn't.
Cyber Surfer
My ISP is currently experiencing news server difficulties.
Apologies if you see this twice...
Erik Naggum
* Mukesh Prasad
| Ah, "compiling to native code" brings up a different issue, that of
| whether or not you want to allow eval in the language. If you do, there
| are some sleigh of hands involved (like hiding an interpreter in your
| language with just the features you like and _can_ compile well?
as has already been mentioned here at the myth-debunking central, many Lisp
systems "interpret" code by compiling it first, then executing the compiled
code. however, the amazing thing is that Lisp systems that don't have
`eval' (Scheme), force the programmers who need to evaluate expressions at
run-time to write their own `eval' look-a-likes. so if you allow lists,
your compiler's input language is lists, and you want to do some hard
things, and if your language does not include `eval', some smart programmer
will have to implement it by himself, and he will in all likelihood not be
smart enough to do _all_ the stuff right that would have been done right in
languages that _did_ include `eval'.
the same goes for many other language features. ever seen a C programmer
try to do dynamic types? he's likely to use a full machine word to keep
the type tag at the beginning of a struct that includes a union of the
types he needs, and will always have to dereference the pointer to find the
type! (and Lisp programmers fret about whether floating point numbers are
"boxed" or not. that's a luxury problem for the general case, where Lisp
is typically _much_ more efficient than even good C programmers would be.)
or a C programmer who wants to build a general list concept? you can bet
your favorite language construct that he will use a lot of `next' pointers
_inside_ each of the structures in the restricted set that can be elements
of his list. this is how textbooks treat the topic, too. messing with
pointers, utilizing the fact that the last three bits of a pointer on a
byte machine will always be zero if all your allocated objects are aligned
to 64 bits, such as a Lisp system can safely do, makes code non-portable,
hard to maintain, etc, and is therefore avoided in all but high-end systems
with big budgets for maintenance (such as Lisp systems).
`eval' is indispensable if you implement your own language. most of the
programs I use actually talk to their users or read configuration files and
so on, which do evaluate expressions read at run-time. one way or the
other, a program that interacts with its users or other programs, may find
itself explicitly or implicitly sporting an `eval' function, albeit for a
very different language than it was itself written in, but that's _also_ a
liability for those programming languages that inherently cannot have
`eval'. e.g., in the C/Unix world, that's what `lex' and `yacc' are for.
in the Lisp world, we already have `read' and `eval'. think about it.
#\Erik
--
Please address private replies to "erik". Mail to "nobody" is discarded.
Kosta Kostis
Bull Horse wrote:
> PASCAL is a 70's langauage. Developed in the early 70's I think 73...
You're right. The preface of the "PASCAL User Manual and Report" states:
A preliminary version of the programming language Pascal was
drafted in 1968. It followed in its spirit the Algol-60 and
Algol-W line of languages. After an extensive development phase,
a first compiler became operational in 1970, and publication
followed a year later (see References 1 and 8, p.104). The
growing interest in the development of compilers for other
computers called for a consolidation of Pascal, and two years of
experience in the use of the language dictated a few revisions.
This led in 1973 to the publication of a Revised Report and a
definition of a language representation in terms of the ISO
characters set.
Yes, Niklaus used a type writer (fixed space) font... ;)
--
kos...@acm.org, ko...@live.robin.de, ko...@blues.sub.de
Kosta Kostis, Talstr. 25, D-63322 Rödermark, Germany
http://ourworld.compuserve.com/homepages/kosta/
Chris
> A language can be called "interpreted", in a non-technical but widely
> used sense, when the implementations most commonly used for production
> applications fail to compile to native code. The Basic dialect used in
> Visual Basic, for example, fits this criterion (though it may not for
> much longer); Lisp doesn't.
A language could be called "compiled" when the code run is different from
the source code, and interpreted when THE source is translated at each
execution.
About native code, we call then a native compiler.
J. Christian Blanchette
>
> What about the Java compiler ? Is the code in machine language ? Isn't it a
> compiler ?
Java source code is plain Unicode text (.java), it is compiled into .class
binaries compatible with the "Java Virtual Machine". The JVM is usually
implemented as an interpreter, although a program could convert Java bytecodes
into native machine code.
Jas.
"I take pride as the king of illiterature."
- K.C.
Mukesh Prasad
Erik Naggum wrote:
>
> as has already been mentioned here at the myth-debunking central, many Lisp
> systems "interpret" code by compiling it first, then executing the compiled
> code.
So that's different from the "sleigh of hand" I mentioned? Are you
a one-person myth-debunking central, or a myth-creation one?
> however, the amazing thing is that Lisp systems that don't have
> `eval' (Scheme), force the programmers who need to evaluate > expressions at
I was expecting people to cite Scheme, T, Nil et al,
but it didn't happen in hordes (though there were very
interesting arguments on the order of "I never use Eval,
therefore Lisp is not interpreted" and "Until more than
N Basic compilers exist, Basic will be an interpreted
language and Lisp will be a compiled language...")
One interesting thing is, I have never seen C mentioned
as a variant of BCPL, and I have seldom seen Pascal
referred to as a kind of Algol. And nobody calls
C++ "a kind of C" anymore. Yet Scheme is even now
a "Lisp system"!
Perhaps instead of drawing fine lines in the sand about
distinctions between interpreted and compiled, and
trying to make being "compiled" the holy grail of Lisp
systems, the Lisp community should have instead tried
to see how well Lisp does as an Internet language!
Nobody cares if Java is an interpreted language, as long as
it does what they need done.
Or on second thoughts, perhaps Lisp could become a Smalltalk
like language -- a source of several ideas, instead
of something in a limbo with always having a small
but vocal minority needing to defend it by claiming
it is not interpreted and such.
Lou Steinberg
In article <55uech$p61$1...@goanna.cs.rmit.edu.au> o...@goanna.cs.rmit.edu.au (Richard A. O'Keefe) writes:
Mukesh Prasad <mpr...@dma.isg.mot.com> writes:
>"Compiled" vs "Interpreted" are merely words
>But if one has to have this distinction, Lisp should
>fall into the "interpreted" category, since the
>"compiled" byte-code is interpreted by sofware, not
>the hardware.
This is complete and utter bull-dust.
... and O'Keefe goes on to list a myriad Lisp systems that compiled to
native code. But Prasad's comment is "bull-dust" for a more basic
reason: By his definition EVERY language
(A) run on a microcoded machine or
(B) compiled for a 68K Mac but run on a PPC Mac
is Interpreted because
(A) on a microcoded machine, what we call "machine code" _is_ just
a byte code that is interpreted by an interpreter written in the 'real'
machine language of this machine, microcode.
(B) on a PPC Mac, 68k machine code is treated as a byte code and
executed by an interpreter.
So the same _binary object code_ can be actual machine code or a byte
code, depending on what machine you run it on. So the notion of a
_language_ being "interpreted" or "compiled" makes no sense. A
particular _implementation_ on an particular _computer_ down to a
particular _level of abstraction_ (e.g., 'down to 68K machine code')
can be "interpreted" or "compiled", but not a language.
William Paul Vrotney
In article <328738...@dma.isg.mot.com> Mukesh Prasad
<mpr...@dma.isg.mot.com> writes:
>
> Erik Naggum wrote:
> >
> > as has already been mentioned here at the myth-debunking central, many Lisp
> > systems "interpret" code by compiling it first, then executing the compiled
> > code.
>
> So that's different from the "sleigh of hand" I mentioned? Are you
> a one-person myth-debunking central, or a myth-creation one?
>
>
> Perhaps instead of drawing fine lines in the sand about
> distinctions between interpreted and compiled, and
> trying to make being "compiled" the holy grail of Lisp
> systems, the Lisp community should have instead tried
> to see how well Lisp does as an Internet language!
> Nobody cares if Java is an interpreted language, as long as
> it does what they need done.
>
Check out
http://www.ai.mit.edu/projects/iiip/doc/cl-http/home-page.html = Common Lisp
Hypermedia Server
> Or on second thoughts, perhaps Lisp could become a Smalltalk
> like language -- a source of several ideas, instead
> of something in a limbo with always having a small
> but vocal minority needing to defend it by claiming
> it is not interpreted and such.
This reads as though Lisp has a mind of it's own. Lisp is good for AI, I
didn't know it was that good! :-)
--
William P. Vrotney - vro...@netcom.com
Erik Naggum
* Mukesh Prasad
| Yet Scheme is even now a "Lisp system"!
it's interesting to see just how little you know of what you speak.
Schemers call Scheme a Lisp system. many Schemers become irate when you
try to tell them that Scheme is not a Lisp.
| Or on second thoughts, perhaps Lisp could become a Smalltalk like
| language -- a source of several ideas, instead of something in a limbo
| with always having a small but vocal minority needing to defend it by
| claiming it is not interpreted and such.
this "source of several ideas" thing has been an ongoing process since its
inception. I'm surprised that you don't know this. people learn from Lisp
(then go off to invent a new syntax) all the time, all over the place.
when I was only an egg, at least I knew it. Mukesh Prasad may want to
investigate the option of _listening_ to those who know more than him,
instead of making a fool out of himself.
Jens Kilian
Mukesh Prasad (mpr...@dma.isg.mot.com) wrote:
> Or on second thoughts, perhaps Lisp could become a Smalltalk
> like language -- a source of several ideas, instead
> of something in a limbo with always having a small
> but vocal minority needing to defend it by claiming
> it is not interpreted and such.
You need to realize that Lisp is the second oldest high-level programming
language. It has always been "a source of several ideas", in that every
functional language has had its roots in Lisp, and lots of stuff has been
carried over into other types of languages as well.
Greetings,
Jens.
--
Internet: Jens_...@bbn.hp.com Phone: +49-7031-14-7698 (TELNET 778-7698)
MausNet: [currently offline] Fax: +49-7031-14-7351
PGP: 06 04 1C 35 7B DC 1F 26 As the air to a bird, or the sea to a fish,
0x555DA8B5 BB A2 F0 66 77 75 E1 08 so is contempt to the contemptible. [Blake]
Mukesh Prasad
Lou Steinberg wrote:
> particular _implementation_ on an particular _computer_ down to a
> particular _level of abstraction_ (e.g., 'down to 68K machine code')
> can be "interpreted" or "compiled", but not a language.
So what on earth is this thread about? Have you
read the topic heading?
You may not be aware of this (actually, you are obviously
not) but books on programming languages tend to divide
languages into two categories, "interpreted" and "compiled".
I repeat, *languages*, not *implementations*.
Since its inception, Lisp has been placed by programming
language theorists in the "interpreted" category.
The language itself, not any particular implementation.
However, Lisp systems have improved in technology.
In the early days, Lisp interpreters directly interpreted
the original source. An obvious improvement was
to "compact" the source code and to get rid of
comments, spaces etc prior to interpretation. But
this does not make the language "compiled".
Another improvement was to replace the original
source code by more compact and easy to interpret
"byte code". The function to do this is called
"compile", hence confusing the typical Lisp user
already.
To confuse matters more, the newer versions of the
"compile" function are more sophisticated, and can generate
machine code into which the interpreter transfers
the flow of control via a machine level jump
instruction. The confusion of the typical modern
day Lisp user is complete at this point!
However, having a function called "compile" doesn't
make language a compiled language.
An interpreted language is one which necessitates baggage
at run-time to interpret it. A compiled language
is one which doesn't. Lisp -- due to the nature
of the language definition -- necessitates baggage at
run-time, even with modern "compile" functions
which can generate machine code.
I will try once more (but not much more, this thread
has not attracted knowledgable responses or
intelligent, unbiased discourse) to explain this -- if the
Lisp language _itself_ is to be deemed "compiled" (irrespective
of any implementation of it), then by that definition,
all languages must be deemed "compiled languages".
For any given language, things which have been
done to Lisp can be done. Thus that language's
definition does not make the language "interpreted"
any more than Lisp is.
>So the same _binary object code_ can be actual machine code or a byte
>code, depending on what machine you run it on. So the notion of a
>_language_ being "interpreted" or "compiled" makes no sense. A
You should read some books on Computer Science. It is
actually a matter of definition, not "sense". It will
only make sense if you are familiar with the definitions.
Otherwise, you might as well look at a book of mathematics
and claim the term "factors" must have something to
do with "fact"s, because that is how you choose to
understand it.
"Interpreted" and "compiled", when applied to
languages, have specific meanings.
>particular _implementation_ on an particular _computer_ down to a
>particular _level of abstraction_ (e.g., 'down to 68K machine code')
>can be "interpreted" or "compiled", but not a language.
This and other such complicated gems occurring in
this thread, are neither compiled nor interpreted, but
simple and pure BS, arising out of ignorance, bias
and lack of clear thinking.
Mukesh Prasad
> it's interesting to see just how little you know of what you speak.
> Schemers call Scheme a Lisp system. many Schemers become irate when you
> try to tell them that Scheme is not a Lisp.
Now if Scheme were a wild success, they would become
irate if you called it Lisp. Amazing how
it works, is it not?
(But I will admit I don't know enough Scheme to debate
how it is or is not Lisp -- I was just making
a point about human behavior...)
> | Or on second thoughts, perhaps Lisp could become a Smalltalk like
> | language -- a source of several ideas, instead of something in a limbo
> | with always having a small but vocal minority needing to defend it by
> | claiming it is not interpreted and such.
> this "source of several ideas" thing has been an ongoing process since its
> inception. I'm surprised that you don't know this. people learn from Lisp
> (then go off to invent a new syntax) all the time, all over the place.
Not too many people, Erik. The Emacs stuff that you _do_ know
about, is more an exception, not a rule. Out here, C and C++ rule,
and Java seems to be on the rise. Lisp is not really
in the picture anymore. A pity, but it made too many promises
and for some reason didn't deliver. I personally suspect it is
because it makes things too easy and encourages lax discipline,
but I may be wrong.
> when I was only an egg, at least I knew it. Mukesh Prasad may want to
Hmmm... If you depend upon things you knew as an egg (i.e.
never bothered to actualy learn,) no wonder you come out
with the proclamations you do!
> investigate the option of _listening_ to those who know more than him,
> instead of making a fool out of himself.
Many times, the only way not to appear a fool to fools is to
join in their foolishness.
Mukesh Prasad
Jens Kilian wrote:
[snip]
> language. It has always been "a source of several ideas", in that every
> functional language has had its roots in Lisp, and lots of stuff has
That's true. Yet, for whatever reasons, none of the functional
languages have matched even the popularity of Lisp
itself, much less surpass it to become one of the highly popular
languages.
William Paul Vrotney
In article <328881...@dma.isg.mot.com> Mukesh Prasad
<mpr...@dma.isg.mot.com> writes:
> Not too many people, Erik. The Emacs stuff that you _do_ know
> about, is more an exception, not a rule. Out here, C and C++ rule,
> and Java seems to be on the rise. Lisp is not really
> in the picture anymore. A pity, but it made too many promises
^
|
Sure, you think it is a pity. What hypocrisy!
Yes you are right Emacs, Lisp and AI are the exception. So why are *you*
posting your predictable opinions to such exceptional news groups? Is it
because you want to advance Emacs, Lisp or AI? ... I don't think so ...
Richard A. O'Keefe
Mukesh Prasad <mpr...@dma.isg.mot.com> writes:
>Ah, "compiling to native code" brings up a different issue,
>that of whether or not you want to allow eval in the
>language. If you do, there are some sleigh of hands
>involved (like hiding an interpreter in your "compiled"
>executable.)
Wrong. A *compiler* in the executable will do fine.
What's more, a *dynamically linked* compiler will also do fine,
so no space need actually be taken up in the object file.
For example, in DEC-10 Prolog, the compiler was a "shared segment"
which was swapped in when you loaded a file and swapped out again
when it had finished.
Take Oberon as another example. Looks like a stripped down Pascal.
Acts like a stripped down Pascal, _except_ it dynamically loads
new modules, and in one implementation, the module loader generates
new native code from a machine-independent compiled format.
>If you don't, is it Lisp?
Well, it might be Scheme...
David Kastrup
Erik Naggum <nob...@naggum.no> writes:
> when I was only an egg, at least I knew it. Mukesh Prasad may want
> to investigate the option of _listening_ to those who know more than
> him, instead of making a fool out of himself.
We'll leave *that* option to people who needn't learn anything or
admit a mistake or even fallability just after they left their egg
state.
--
David Kastrup Phone: +49-234-700-5570
Email: d...@neuroinformatik.ruhr-uni-bochum.de Fax: +49-234-709-4209
Institut f=FCr Neuroinformatik, Universit=E4tsstr. 150, 44780 Bochum, Germa=
ny
Richard A. O'Keefe
Mukesh Prasad <mpr...@dma.isg.mot.com> writes:
>However, Lisp systems have improved in technology.
>In the early days, Lisp interpreters directly interpreted
>the original source.
Lisp 1.5 had a compiler.
No "mainstream" Lisp interpreter has _ever_ "directly interpreted
the original source".
(I have seen an interpreter for a C-like language that did exactly
that. It was in a book by Herbert Schildt, and as you might expect
it was seriously inefficient.)
Lisp interpreters deal with _abstract syntax trees_.
>An obvious improvement was
>to "compact" the source code and to get rid of
>comments, spaces etc prior to interpretation. But
>this does not make the language "compiled".
Once again, _all_ Lisp systems since 1.5 and before have
been based on abstract syntax trees, and most of them have
had _both_ an interpreter walking these trees (for debugging)
_and_ a compiler generating code (for execution).
>Another improvement was to replace the original
>source code by more compact and easy to interpret
>"byte code". The function to do this is called
>"compile", hence confusing the typical Lisp user
>already.
I once used a byte coded system, a Xerox 1108.
Thing was, the byte codes WERE THE NATIVE INSTRUCTION SET
of the machine. There was microcode underneath, but
there was microcode underneath the IBM 360 and M68000,
and nobody ever slammed BAL/360 for being an "interpreted"
language.
And again: the PSL system I was using in the 70s compiled
to *native* *instructions*.
>To confuse matters more, the newer versions of the
>"compile" function are more sophisticated, and can generate
>machine code into which the interpreter transfers
>the flow of control via a machine level jump
>instruction. The confusion of the typical modern
>day Lisp user is complete at this point!
Maybe you are confused, but Lisp users are not.
As far as a Lisp user is concerned, the question is
simply "do I get fine grain debugging, or do I get
high performance".
>However, having a function called "compile" doesn't
>make language a compiled language.
No, but in the 60s and 70s the mainstream Lisp
systems included the ability to compile to native machine
instructions, and this facility was *routinely* used.
Tell me this, and tell me honestly:
what properties does Scheme have (or lack)
compared with Fortran
that make Scheme "interpreted" and Fortran "compiled".
When you are answering this, consider the fact that I use
a Scheme compiler which is a "batch" compiler producing
code that often outperforms C, and the fact that I have
read a Fortran interpreter that was used to execute student
programs.
>An interpreted language is one which necessitates baggage
>at run-time to interpret it.
You haven't defined what "interpret" means.
Using any of several reasonable criteria, this makes Fortran and
C interpreted languages.
>A compiled language
>is one which doesn't. Lisp -- due to the nature
>of the language definition -- necessitates baggage at
>run-time, even with modern "compile" functions
>which can generate machine code.
Ah, but that "baggage" you are ranting about
- need not occupy any space in the executable form of the program
- need not take any *time* at run time unless it is actually *used*
- exists for C on UNIX, Windows, VMS, and other modern operating systems.
What am I getting at with that last point?
This:
A C program may *at run time* construct new code,
cause it to be compiled,
and cause it to become part of the running program.
There isn't any special _syntax_ for this, but it's in the _API_.
Presuambly you know about Windows DLLs; in UNIX SVr4 look for
'dlopen' in the manuals; in VMS I don't know what it's called but
I've used a program that used it. The CMS operating system has
had a dynamic LOAD command for a very long time.
However, calling compilation interpreting simply because it
happens at run time is a bizarre abuse of the English language.
>I will try once more (but not much more, this thread
>has not attracted knowledgable responses or
It has. People have tried to tell you that Lisp systems have
been generating native machine code for decades, since very early
days indeed. You keep calling them interpreters.
>intelligent, unbiased discourse)
You appear to accept only people who agree with you as unbiased.
to explain this -- if the
>Lisp language _itself_ is to be deemed "compiled"
With the notable exception of yourself, most people have
been arguing that it is EXTREMELY SILLY to call *ANY* language
"compiled" or "interpreted".
What people have been saying is that mainstream Lisp *SYSTEMS*
have since the earliest days offered compilers for the Lisp
language.
>(irrespective
>of any implementation of it),
Nobody in his right mind would so deem *any* programming language.
*Any* programming language can be interpreted.
Just about all of them *have* been. (There is at least one C++ interpreter.)
*Some* programming languages are hard to compile; APL2 springs to mind
because the *parsing* of an executable line can vary at run time. Even
so, there are *systems* that can reasonably be called APL compilers.
Another language that I would _hate_ to have to compile is M4; once
again the syntax can change while the program is executing.
>>So the same _binary object code_ can be actual machine code or a byte
>>code, depending on what machine you run it on. So the notion of a
>>_language_ being "interpreted" or "compiled" makes no sense. A
>You should read some books on Computer Science.
Lou Steinberg has probably read a *lot* of them.
>It is actually a matter of definition, not "sense". It will
>only make sense if you are familiar with the definitions.
>Otherwise, you might as well look at a book of mathematics
>and claim the term "factors" must have something to
>do with "fact"s, because that is how you choose to
>understand it.
This paragraph does not suggest any very profound acquaintance
with _either_ computing _or_ mathematics. One of the problems
that plagues both disciplines is that terminology and notation
are used differently by different authors. Most of the serious
mathematics and formal methods books I have include, BECAUSE
THEY NEED TO, a section explaining the notation they use.
>"Interpreted" and "compiled", when applied to
>languages, have specific meanings.
There are no *standard* meanings for those terms when applied to
languages. Why don't you cite the definitions and where you
found them?
For now, I've searched my fairly full bookshelves, and failed to
find any such definition. Amusingly, I did find the following
paragraph in the classic
Compiler Construction for Digital Computers
David Gries
Wiley International Edition, 1971.
At the beginning of Chapter 16, "Interpreters", we find this:
We use the term _interpreter_ for a program which performs
two functions:
1. Translates a source program written in the source language
(e.g. ALGOL) into an internal form; and
2. Executes (interprets, or simulates) the program in this
internal form.
The first part of the interpreter is like the first part of
a multi-pass cmpiler, and we will call it the "compiler".
The issue as Gries saw it back in 1971 (and I repeat that this is a
classic textbook) was between an internal form executed by software
and an internal form executed by hardware.
The question is, what are you trying to do in this thread?
Are you
(A) trying to make some substantive point about Lisp compared with
other languages?
In that case you have been proved wrong. There is no _useful_
sense in which Lisp is more "interpreted" than C, in existing
practical implementations of either.
(B) trying to make a _terminological_ point with no consequences for
what _happens_ to a program, only for what it is _called_?
In that case, you should be aware that you are NOT using
words in a way intelligible to people who have actually
*worked* on compilers, and you should explicitly state what
definitions you are using and where you got them.
The only point I care about is (A), whether there is any intrinsic
inefficiency in Lisp compared with C, and the answer is NO, there
isn't:
A programming language that is widely accepted as a Lisp dialect
(Scheme) not only _can_ be "batch" compiled like C, I routinely
use just such a compiler and get the same or better performance
out of it. (This is the Stalin compiler.)
In all the "popular" operating systems these days: DOS, Windows,
most modern UNIX systems, VMS, CMS, it is possible for a C
program to dynamically construct new code which then becomes
part of the running program.
Any book which states or implies that there is something about
"Lisp" (not otherwise specified as to dialect) is intrinsically
"interpreted" is not to be discarded lightly, but to be hurled
with great force.
Jens Kilian
Mukesh Prasad (mpr...@dma.isg.mot.com) wrote:
[...]
> "Interpreted" and "compiled", when applied to
> languages, have specific meanings.
_Any_ programming language can be implemented by an interpreter or a compiler.
It just doesn't make sense to speak about "compiled languages" vs "interpreted
languages". I take it that you have never heard about C interpreters?
[...]
> This and other such complicated gems occurring in
> this thread, are neither compiled nor interpreted, but
> simple and pure BS, arising out of ignorance, bias
> and lack of clear thinking.
*Plonk*
Pot, kettle, black etc.
Cyber Surfer
In article <328738...@dma.isg.mot.com>
mpr...@dma.isg.mot.com "Mukesh Prasad" writes:
> I was expecting people to cite Scheme, T, Nil et al,
> but it didn't happen in hordes (though there were very
> interesting arguments on the order of "I never use Eval,
> therefore Lisp is not interpreted" and "Until more than
> N Basic compilers exist, Basic will be an interpreted
> language and Lisp will be a compiled language...")
Check my email to you, and you'll find Scheme mentioned.
EVAL is a relic from an ancient time.
> One interesting thing is, I have never seen C mentioned
> as a variant of BCPL, and I have seldom seen Pascal
> referred to as a kind of Algol. And nobody calls
> C++ "a kind of C" anymore. Yet Scheme is even now
> a "Lisp system"!
Scheme is just a dialect of Lisp. VB is a dialect of Basic,
but who calls it Basic? The name distinguishes it from other
dialects.
Sadly, some people simply refer to Common Lisp as "Lisp".
This can be confusing. If you want a short name, refer to
it as CL. When I refer to Lisp, I include CL, Scheme, Dylan,
and anything else that is Lisp-like. Check the Lisp FAQ
for examples.
> Perhaps instead of drawing fine lines in the sand about
> distinctions between interpreted and compiled, and
> trying to make being "compiled" the holy grail of Lisp
> systems, the Lisp community should have instead tried
> to see how well Lisp does as an Internet language!
> Nobody cares if Java is an interpreted language, as long as
> it does what they need done.
I'm one of the few Lisp programmers who'd like to see Lisp
become more popular. I guess most people are happy with Lisp
the way it is.
> Or on second thoughts, perhaps Lisp could become a Smalltalk
> like language -- a source of several ideas, instead
> of something in a limbo with always having a small
> but vocal minority needing to defend it by claiming
> it is not interpreted and such.
Actually, it's only fools like youself calling it interpreted
that cause problems. You're confusing implementation details
with the language. Read a few books on compiler theory, esp
books like Brown's. <hint, hint>
--
<URL:http://www.enrapture.com/cybes/> You can never browse enough
Dave Newton
Richard A. O'Keefe wrote:
> What am I getting at with that last point?
> This:
>
> A C program may *at run time* construct new code,
> cause it to be compiled,
> and cause it to become part of the running program.
>
> There isn't any special _syntax_ for this, but it's in the _API_.
> Presuambly you know about Windows DLLs; in UNIX SVr4 look for
> 'dlopen' in the manuals;
I'm confused on your point here-DLLs aren't compiled or "constructed"
at load time. I could, I suppose, spawn off a compile/link process and
create a DLL then explicitly load it, but I don't think that counts.
> In all the "popular" operating systems these days: DOS, Windows,
> most modern UNIX systems, VMS, CMS, it is possible for a C
> program to dynamically construct new code which then becomes
> part of the running program.
I used to do that on my TRaSh-80 by writing machine language into
string space. Worked pretty well. That counts. Dynamically-linked libraries
don't, IMHO. If you want to modify machine code inside a code or data
segment that probably _would_ count, but it's pretty much a pain to do.
--
Dave Newton | TOFU | (voice) (970) 225-4841
Symbios Logic, Inc. | Real Food for Real People. | (fax) (970) 226-9582
2057 Vermont Dr. | | david....@symbios.com
Ft. Collins, CO 80526 | The World Series diverges! | (Geek joke.)
Scott Nudds
(Patrick Juola) wrote:
: You're palming a card. C, a compiled language by anyone's reckoning,
: has no (single) hardware instruction corresponding to printf.
Printf is an interpreter.
--
<---->
Cyber Surfer
In article <328879...@dma.isg.mot.com>
mpr...@dma.isg.mot.com "Mukesh Prasad" writes:
> You may not be aware of this (actually, you are obviously
> not) but books on programming languages tend to divide
> languages into two categories, "interpreted" and "compiled".
> I repeat, *languages*, not *implementations*.
Some people may bever have used a language where the distinction
is hard to make.
Take Forth as an example. Is Forth compiled or interpreted? It
depends on how your definition, but there are Forths that generate
native code. One of my batch Forth compilers generated assembly
source code, while a later version generates threaded code.
Interactive Forths can compile to either native or threaded code.
You could even argue that the Novix compiler generates _microcode_,
but since the code is 16bit, that may be debatable. Can microcode
be 16bit? Perhaps. Perhaps not.
If you run x86 code on an emulator, is that interpreted? Is it
still "native"? Who cares?
> Since its inception, Lisp has been placed by programming
> language theorists in the "interpreted" category.
> The language itself, not any particular implementation.
In which category did PJ Brown put Lisp? Or Basic...
There are C interpreters. So what?
The language theorists may not be the ones who decide these things.
It could be the marketing people. We should also ask _when_ these
categorisations were made. You didn't say, did you? By playing the
same game, I could say that C is an obscure novelty that few people
have heard of, never mind actually use. I could also say that it
was only available for Unix. However, I won't, because it would no
longer be true.
> However, Lisp systems have improved in technology.
> In the early days, Lisp interpreters directly interpreted
> the original source. An obvious improvement was
> to "compact" the source code and to get rid of
> comments, spaces etc prior to interpretation. But
> this does not make the language "compiled".
This is just history. Very old history. See above.
> Another improvement was to replace the original
> source code by more compact and easy to interpret
> "byte code". The function to do this is called
> "compile", hence confusing the typical Lisp user
> already.
Basic used to do this, and perhaps still does. Which Basic, tho?
VB? No. QuickBasic? ST Basic? BBC Basic?
> To confuse matters more, the newer versions of the
> "compile" function are more sophisticated, and can generate
> machine code into which the interpreter transfers
> the flow of control via a machine level jump
> instruction. The confusion of the typical modern
> day Lisp user is complete at this point!
What confusion? All I see here is the bollocks that you're talking.
You're talking history, which most people will ignore.
> However, having a function called "compile" doesn't
> make language a compiled language.
Not necessailry, but producing native code might. Do you mean
"compile to native code"? It's not clear - perhaps you're confusing
the word compile with some special meaning that only you know?
See PJ Brown's book for my choice. What's yours?
> An interpreted language is one which necessitates baggage
> at run-time to interpret it. A compiled language
> is one which doesn't. Lisp -- due to the nature
> of the language definition -- necessitates baggage at
> run-time, even with modern "compile" functions
> which can generate machine code.
Most, if not all. langauges necessitates runtime baggage.
Perhaps you hadn't noticed this. C is a perfect example.
Very few programmes use it without the standard C library.
Some of us call the OS directly - which can be thought of
as an even larger runtime! Ok, that's bryond the scope of
the langauge, but since you're so intent on confusing the
issue with misinformation, why not? Some Lisps run without
the support of what most people would call an OS. So do
some Basics...
> I will try once more (but not much more, this thread
> has not attracted knowledgable responses or
> intelligent, unbiased discourse) to explain this -- if the
> Lisp language _itself_ is to be deemed "compiled" (irrespective
> of any implementation of it), then by that definition,
> all languages must be deemed "compiled languages".
Now you're getting it! See PJ Brown's book. The words "compile"
and "interpret" are a distraction that'll only confuse you.
> For any given language, things which have been
> done to Lisp can be done. Thus that language's
> definition does not make the language "interpreted"
> any more than Lisp is.
That's a good argument for not make such distinctions,
and yet you insist on making them, as if they still mean
anything.
> >So the same _binary object code_ can be actual machine code or a byte
> >code, depending on what machine you run it on. So the notion of a
> >_language_ being "interpreted" or "compiled" makes no sense. A
>
> You should read some books on Computer Science. It is
> actually a matter of definition, not "sense". It will
> only make sense if you are familiar with the definitions.
Ah, but _which_ CS books? Whose definitions? Let's have
some modern definitions, from the last 20 years or so.
In fact, we could go back a lot further than that and
still find that distinctions like yours are misplaced.
It's better to look at it all as merely data. In Turing's
day, this may have been better understood, but more
recently, we've been unnecessarily obsessed with hardware.
Finally, attention seems to be shifting back to the notion
that the hardware details are...just details, like any of
information inside a computer. Even marketing people are
becoming aware of it!
> Otherwise, you might as well look at a book of mathematics
> and claim the term "factors" must have something to
> do with "fact"s, because that is how you choose to
> understand it.
Now you're being silly again. Wake up and smell the coffee!
How long have you been asleep?
> "Interpreted" and "compiled", when applied to
> languages, have specific meanings.
No they don't. You're talking about _implementations_,
not languages. There is a difference, y'know. This lack
of understanding doesn't help your credibility.
> >particular _implementation_ on an particular _computer_ down to a
> >particular _level of abstraction_ (e.g., 'down to 68K machine code')
> >can be "interpreted" or "compiled", but not a language.
>
> This and other such complicated gems occurring in
> this thread, are neither compiled nor interpreted, but
> simple and pure BS, arising out of ignorance, bias
> and lack of clear thinking.
Wanna bet? Have you noticed how many emulators for the
instruction sets of major CPUs are available today? Intel
are working on their next generation of CPUs, which will
emulate the x86 familiy. Is that BS? Perhaps, as most of
us have only Intel's word that this is what they're doing.
However, they're not the only ones persuing this line.
Digital also have an x86 emulator, and others have produced
emulators before them. It's a rather _old_ idea.
You've mentioned CS books, so I wonder if you've read Vol 1
of Knuth's Art of Computer Programming? Take a look at the
Mix "machine" that he describes. It might just as well be
a real machine for all we care, and that's the point. Mix
allowed him to write code for a specific archetecture, which
can be useful for certain areas of programming, like writing
a floating point package - or a compiler.
You might also want to take a look at the Pascal P4 compiler,
and the portable BCPL compiler. There are books documenting
them. Oh, and let's not forget the VP code used by Tao (see
<URL:http://www.tao.co.uk> for details).
The weight of evidence against must be crushing you. ;-)
Cyber Surfer
In article <328881...@dma.isg.mot.com>
mpr...@dma.isg.mot.com "Mukesh Prasad" writes:
> Now if Scheme were a wild success, they would become
> irate if you called it Lisp. Amazing how
> it works, is it not?
This is a hypothetical question. It might not happen that way at
all, and my personal opinion is that this is more likely. Whatever
Scheme's success may be, I think that Scheme and CL programmers
can life together far more harmoniously than C and Pascal programmers
ever could. so, I doubt anybody will make a fuss.
Besides, you didn't say anthing about Scheme being more successful
than CL, did you? ;-)
> (But I will admit I don't know enough Scheme to debate
> how it is or is not Lisp -- I was just making
> a point about human behavior...)
Noted. It's your point, not mine. While C and Pascal programmers
may behave that way, I've not noticed CL and Schemer programmers
being so childish. Ah, but using Lisp is a sign of muturity! ;-)
> Not too many people, Erik. The Emacs stuff that you _do_ know
> about, is more an exception, not a rule. Out here, C and C++ rule,
> and Java seems to be on the rise. Lisp is not really
> in the picture anymore. A pity, but it made too many promises
> and for some reason didn't deliver. I personally suspect it is
> because it makes things too easy and encourages lax discipline,
> but I may be wrong.
Yes, you may be wrong. My suspicion, based on the opinions of
C++ programmers that I've seen posted to UseNet, is that some
people just like programming to be _difficult_, and refuse to
use anything "too easy". In fact, they'll go further, and claim
that such tools can't be used.
This is curious behavious, considering the evidence to the
contrary. However, this evidence is frequently drawn to their
attention, in such discussions, and the issue is forgotten.
> Hmmm... If you depend upon things you knew as an egg (i.e.
> never bothered to actualy learn,) no wonder you come out
> with the proclamations you do!
What have you learned, eh? C'mon, quote some references that
support your assertions. Then we might have something to discuss.
> > investigate the option of _listening_ to those who know more than him,
> > instead of making a fool out of himself.
>
> Many times, the only way not to appear a fool to fools is to
> join in their foolishness.
As I'm doing. ;-) I could just ignore you, but it's more fun
to this way. We're playing the "who knows more about compilers"
game, in which nobody scores any points (none that count, anyway),
there are no prizes (just the survival of death of certain memes),
and we can all walk away thinking, "Well, that showed him!"
It would be very childish, if this kind of stupidity didn't effect
the nature of the software we use and the tools used to create it.
The effect may be small, it every meme and every head those memes
live in plays its part.
Erik Naggum
* Mukesh Prasad
| Since its inception, Lisp has been placed by programming language
| theorists in the "interpreted" category. The language itself, not any
| particular implementation.
this should make you think very carefully about the qualifications of those
"programming language theorists".
| However, Lisp systems have improved in technology. In the early days,
| Lisp interpreters directly interpreted the original source.
the `read' function, which transforms a character string (the original
source) into lists/trees, has been with the language since the very
earliest days. nothing ever saw the original source code in the Lisp
system apart from this function, called the Lisp reader.
| An obvious improvement was to "compact" the source code and to get rid of
| comments, spaces etc prior to interpretation.
you have no inkling of a clue to what you talk about.
| Another improvement was to replace the original source code by more
| compact and easy to interpret "byte code".
geez. it appears that your _only_ exposure to "interpreted" languages are
BASIC systems. it is quite unbelievable that anyone should want to parade
the kind of ignorance you display across so many newsgroups.
| To confuse matters more, the newer versions of the "compile" function are
| more sophisticated, and can generate machine code into which the
| interpreter transfers the flow of control via a machine level jump
| instruction.
let me guess. you're an old ZX-80, TRS-80, CBM-64, etc, hacker, right?
you know the way the old BASIC interpreters worked, by heart, right? and
you think "interpreter" has to mean the same thing for toy computers in the
early 80's and a language "designed primarily for symbolic data processing
used for symbolic calculations in differential and integral calculus,
electrical circuit theory, mathematical logic, game playing, and other
fields of artificial intelligence" (McCarthy, et al: Lisp 1.5; MIT Press,
1962) in the early 60's.
| "Interpreted" and "compiled", when applied to languages, have specific
| meanings.
this is perhaps the first true statement I have you make in several weeks.
however, the specific meanings are not the ones you have in mind.
| This and other such complicated gems occurring in this thread, are
| neither compiled nor interpreted, but simple and pure BS, arising out of
| ignorance, bias and lack of clear thinking.
right. I was about to flame you for being a moron, so thanks for laying
the foundation. you don't know what you're talking about, you don't know
what Lisp is like, you don't know any of Lisp's history, you refuse to
listen when people tell you, and, finally, you don't seem to grasp even the
simplest of ideas so that you can express them legibly. in brief, you're a
moron. I sincerely hope that Motorola made an error in hiring you.
Erik Naggum
* Mukesh Prasad
| > when I was only an egg, at least I knew it. Mukesh Prasad may want to
|
| to actualy learn,) no wonder you come out with the proclamations you do!
the expression "I am only an egg" refers to Robert A. Heinlein's legendary
"Stranger on a Strange Land". so does the word "grok", which I assume is
even more unfamiliar to you, both as a concept and as a word. it was first
published in 1961. at that time I was _literally_ only an egg, but that is
not what the expression refers to.
Lou Steinberg
I pointed out _reasons_ why calling a language compiled or interpreted
made little sense. Prasad responded with several appeals to authority:
books on programming languages tend to divide
languages into two categories, "interpreted" and "compiled".
I repeat, *languages*, not *implementations*.
Since its inception, Lisp has been placed by programming
language theorists in the "interpreted" category.
The language itself, not any particular implementation.
Can you cite any sources to back up these claims? I flatly do not believe
them. Please tell us which "books on programming languages" you are
referring to. Were they published within the last 20 years?
Can you direct us to any statement in the literature by any
programming language theorist that supports this claim?
In the early days, Lisp interpreters directly interpreted
the original source. An obvious improvement was
to "compact" the source code and to get rid of
comments, spaces etc prior to interpretation.
This is complete nonsense. One of the interesting features of _all_
interpreted implementations of Lisp, from the very first, was that
they did not interpret a character string but rather the internal
linked-list ("s-expression") representation. See, e.g., "Programming in
the Interactive Environment" by Erik Sandewall, Computing Surveys,
V. 10, # 1, March 1978, for a discussion of some of the consequences
of this approach.
--------------------------------------------------------------------
Prof. Louis Steinberg l...@cs.rutgers.edu
Department of Computer Science http://www.cs.rutgers.edu/~lou
Rutgers University
Jeff Barnett
In article <56bv0i$lm0$1...@goanna.cs.rmit.edu.au>, o...@goanna.cs.rmit.edu.au (Richard A. O'Keefe) writes:
|> Mukesh Prasad <mpr...@dma.isg.mot.com> writes:
|> >Ah, "compiling to native code" brings up a different issue,
|> >that of whether or not you want to allow eval in the
|> >language. If you do, there are some sleigh of hands
|> >involved (like hiding an interpreter in your "compiled"
|> >executable.)
|>
|> Wrong. A *compiler* in the executable will do fine.
|> What's more, a *dynamically linked* compiler will also do fine,
|> so no space need actually be taken up in the object file.
Just a foolow up to the above: in a LIsp I implemented for the old
IBM 360/370 line, eval just called the compiler, ran the native code
produced, marked the function for garbage collect, then returned the
values. BTW, the reason for this was that I detested the way other
Lisp's had/enjoyed differences between compiler and eval semantics.
Jeff Barnett
Tim Olson
In article <328879...@dma.isg.mot.com>
Mukesh Prasad <mpr...@dma.isg.mot.com> writes:
> You may not be aware of this (actually, you are obviously
> not) but books on programming languages tend to divide
> languages into two categories, "interpreted" and "compiled".
> I repeat, *languages*, not *implementations*.
What books are those? The ones I have read specifically state that it
is the *implementation* which can be divided into the two extremes of
"interpreted" (simulated) and "compiled" (translated). Some go on to
classify languages into these categories based upon the most common
*implementations*.
> Since its inception, Lisp has been placed by programming
> language theorists in the "interpreted" category.
> The language itself, not any particular implementation.
>
> However, Lisp systems have improved in technology.
> In the early days, Lisp interpreters directly interpreted
> the original source. An obvious improvement was
> to "compact" the source code and to get rid of
> comments, spaces etc prior to interpretation.
LISP systems never "directly interpreted the original source" --
rather, they convert input source to internal list representations of
"S-expressions". Comments and spaces are removed by the read
procedure.
> But
> this does not make the language "compiled".
"In the early days", LISP existed in both interpreted and compiled
forms. Read McCarthy's LISP1.5 Programmer's Manual (1965), which
describes the interpreter and the compiler (which generated IBM 7090
assembly language).
> An interpreted language is one which necessitates baggage
> at run-time to interpret it. A compiled language
> is one which doesn't. Lisp -- due to the nature
> of the language definition -- necessitates baggage at
> run-time, even with modern "compile" functions
> which can generate machine code.
What runtime baggage does the language LISP *require*? One might say
"garbage collection", but that can be considered a "helper function",
just like heap allocation via malloc() is for C.
-- Tim Olson
Apple Computer, Inc.
(t...@apple.com)
Patrick Juola
Bingo! Thank you for so eloquently pouncing on the point I've been
trying to make for some time now.
Patrick
CHRISTOPHER ELIOT
In article <LOU.96No...@atanasoff.rutgers.edu>,
Lou Steinberg <l...@cs.rutgers.edu> wrote:
>I pointed out _reasons_ why calling a language compiled or interpreted
>made little sense. Prasad responded with several appeals to authority:
>
> languages into two categories, "interpreted" and "compiled".
> I repeat, *languages*, not *implementations*.
Dividing languages into interpreted and compiled is like saying that
"trucks run on diesel fuel and cars run on gasoline". It may be a
valid generalization, but there are exceptions. The terms "interpreter"
and "compiler" describe features of an implementation not a language.
I don't know what kind of "authority" it takes to be convincing
about this distinction. I was part of the implementation team
at MIT that wrote a Lisp compiler for the VAX in the mid 1980's.
You can look in the proceeedings of AAAI-96 for my paper
describing how I used a Lisp compiler to model multi-agent
reasoning. In fact, I wrote an interpreter for a simulation
langauge to do that.
> Since its inception, Lisp has been placed by programming
> language theorists in the "interpreted" category.
> The language itself, not any particular implementation.
>
>Can you cite any sources to back up these claims? I flatly do not believe
>them. Please tell us which "books on programming languages" you are
>referring to. Were they published within the last 20 years?
>Can you direct us to any statement in the literature by any
>programming language theorist that supports this claim?
> In the early days, Lisp interpreters directly interpreted
> the original source. An obvious improvement was
> to "compact" the source code and to get rid of
> comments, spaces etc prior to interpretation.
>
>This is complete nonsense. One of the interesting features of _all_
>interpreted implementations of Lisp, from the very first, was that
>they did not interpret a character string but rather the internal
>linked-list ("s-expression") representation. See, e.g., "Programming in
>the Interactive Environment" by Erik Sandewall, Computing Surveys,
>V. 10, # 1, March 1978, for a discussion of some of the consequences
>of this approach.
>--------------------------------------------------------------------
>Prof. Louis Steinberg l...@cs.rutgers.edu
>Department of Computer Science http://www.cs.rutgers.edu/~lou
>Rutgers University
--
Christopher R. Eliot, Senior Postdoctoral Research Associate
Center for Knowledge Communication, Department of Computer Science
University of Massachusetts, Amherst. (413) 545-4248 FAX: 545-1249
EL...@cs.umass.edu, http://rastelli.cs.umass.edu/~ckc/people/eliot/
Carl Donath
Jens Kilian wrote:
> _Any_ programming language can be implemented by an interpreter or a compiler.
> It just doesn't make sense to speak about "compiled languages" vs "interpreted
> languages". I take it that you have never heard about C interpreters?
This does not take into account languages (Lisp, APL) where the program
may generate functions and execute them. A compiler could only do this
if the compiled program included a compiler to compile and execute the
generated-on-the-fly instructions, which is difficult and/or silly.
In a phrase, "self-modifying code".
--
----------------------------------------------------------------------
-- c...@nt.com ----- ctdo...@rpa.net ----- ctdo...@mailbox.syr.edu --
----------------------------------------------------------------------
Cyber Surfer
In article <3289ED...@symbiosNOJUNK.com>
david....@symbiosNOJUNK.com "Dave Newton" writes:
> I used to do that on my TRaSh-80 by writing machine language into
> string space. Worked pretty well. That counts. Dynamically-linked libraries
> don't, IMHO. If you want to modify machine code inside a code or data
> segment that probably _would_ count, but it's pretty much a pain to do.
I also POKEed machine code into string space, as well as writing
Basic code that wrote assembly source code. My first compile took
the display memory map and wrote the code for a program to load
it back in, with the load address set for the memory map. Yes,
I used a TRS-80! I learned a lot from that "mess" of a machine,
perhaps _because_ of all its faults.
While I've not yet written machine code to a data segment and then
created a code alias for it, it doesn't look hard to do. The "hard"
part is the bit that writies the machine code. Having written an
assembler in Forth, and various Forth compilers, I think I understand
the principles. Still, all I'm saying is that I _could_ do it if
I ever had a good reason to. So far, I haven't.
However, I may prefer doing it that way to writing - let's say - C
source code that then using a C compiler, esp if the app/util/whatever
has to be delivered to a client who almost certainly won't have a
C compiler or any other development tool. Whether this is preferable
to writing a bytecode interpreter, and compiling to bytecodes, will
likely depend on the requirements of the program in which you're
embedding this code. If the compiled code won't survive after the
the program stops running, then using machine code may actually be
_easier_ than bytecodes.
Alternately, there's threaded code, but if the addresses are direct,
i.e. direct threading, then a change to the program will, like the
machine code approach, require all the code from your compile to be
recompiled, thus updating the addresses to match the runtime.
Complicated, isn't it? ;-) Even writing about it can be messy, but
I find it easier to write the code than to write _about_ the code.
PJ Brown explained it much better than I can!
So, I'm not disagreeing with either of you. Richard is right, you
can count a DLL, _if_ you have the tools to create a DLL handy when
your program runs. If not, then your point will be valid.
Cyber Surfer
In article <3288BB...@dma.isg.mot.com>
mpr...@dma.isg.mot.com "Mukesh Prasad" writes:
> That's true. Yet, for whatever reasons, none of the functional
> languages have matched even the popularity of Lisp
> itself, much less surpass it to become one of the highly popular
> languages.
15 years ago, the same might've been said about OOP. All
you're telling us is where we currently stand in the history
of functional languages. I think we already know that.
Once again, you're trying to confuse the issue by misrepresenting
the facts. It doesn't help your argument. In fact, you appear
to be rather "clueless" when it comes to compile theory. While
Richard Gabriel has suggested some excellent books on the subject,
I'd recommend that you start with something more basic, and which
specifically explains how compiler theory relates to _interactive_
language systems.
You, on the other hand, have not given any references for
your sources of information. Where's _your_ credibility?
C'mon, put up or shut up. ;-)
It could just be that you're confusing "interactive" with
"interpreted". The two are _not_ the same, as you would be
aware by now if you were paying attention. So, kindly go away
and start reading (and hopefully _learning_ from) some of
these books, and then come back when you can refrain from
trying to teach your grandmother to suck eggs.
The difference between ignorance and stupidity is that an
ignorant person can be educated. Well, we've done our best
to help you in this regard. The next bit is all down to you.
Good luck!
Mukesh Prasad
Richard A. O'Keefe wrote:
> cause it to be compiled,
> and cause it to become part of the running program.
True, but extremely contrived and misleading. Yes, it is possible
to execute "cc" from a C program. No, it is not necessary
for C programs to bundle "cc" with the C executable.
The case you are talking about is no different from
a particular C program needing to execute "ls", and
therefore needing "ls" to be bundled with it. There
are no intrinsic language features requiring such bundling. With
Lisp, there are, which is the basic difference. (You
may choose not to use those particular language features,
but that is your own business.)
> With the notable exception of yourself, most people have
> been arguing that it is EXTREMELY SILLY to call *ANY* language
> "compiled" or "interpreted".
Actually, nobody has been arguing along the lines of "this thread
is meaningless, because there is no such thing as an
'interpreted language'." Now that, I would have
considered honest and unbiased opinion. This argument
is only pulled out, somehow, in _defense_ of the thread!
> A programming language that is widely accepted as a Lisp dialect
> (Scheme) not only _can_ be "batch" compiled like C, I routinely
> use just such a compiler and get the same or better performance
> out of it. (This is the Stalin compiler.)
This thread is not about Scheme, but Lisp.
Mukesh Prasad
Richard A. O'Keefe wrote:
>
... A *compiler* in the executable will do fine.
> What's more, a *dynamically linked* compiler will also do fine,
> so no space need actually be taken up in the object file.
Correct, "hiding an interpreter" was an example strategy.
But you must hide *something* in the run-time environment,
and invoke it at run-time. As opposed to doing it
all at compile time.
Whether or not it takes up extra space, and whether
or not it is dynamically linked, is an operating
system dependent issue, and is not relevant from
a language point of view. (But if you are just
trying to get people to be interested in Lisp, it is
an actual issue of concern. But laying and defending a false
foundation ir order to raise interest, does not give
one a good start.)
> >If you don't, is it Lisp?
> Well, it might be Scheme...
Sure. So why not say what you mean, instead
of talking about Lisp and switching to
a particular dialect in the middle?
Mukesh Prasad
Cyber Surfer wrote:
[snip]
>Actually, it's only fools like youself calling it interpreted
>that cause problems. You're confusing implementation details
>with the language. Read a few books on compiler theory, esp
>books like Brown's. <hint, hint>
Now what was the provocation for all these direct insults?
I am not singling you out -- but it seems a lot of
modern-day Lispers have been resorting to such tactics.
Well, at least it makes me glad I am not doing any more Lisp,
I might have been working with people like this!
Mukesh Prasad
Jens Kilian wrote:
> _Any_ programming language can be implemented by an interpreter or a compiler.
> It just doesn't make sense to speak about "compiled languages" vs "interpreted
> languages". I take it that you have never heard about C interpreters?
>
That's a self-consistent set of definitions, but I didn't notice
you jumping in to say "this topic is meaningless because
there is no such thing as an interpreted language"?
If you are trying to use the term "interpreted language",
you must go by its past usage. Tactics like switching the meaning,
terms and subject in the middle of a discussion may be legitimate
in certain fields, but hopefully not in a technical
discussion on programming.
Jens Kilian
Carl Donath (c...@cci.com) wrote:
> Jens Kilian wrote:
> > _Any_ programming language can be implemented by an interpreter or a compiler.
> > It just doesn't make sense to speak about "compiled languages" vs "interpreted
> > languages". I take it that you have never heard about C interpreters?
> This does not take into account languages (Lisp, APL) where the program
> may generate functions and execute them. A compiler could only do this
> if the compiled program included a compiler to compile and execute the
> generated-on-the-fly instructions, which is difficult and/or silly.
It is neither difficult nor silly. Several Prolog systems are doing this,
and the SELF language is also compiled on-the-fly.
> In a phrase, "self-modifying code".
As long as it's done in a structured fashion (i.e., generate a whole new
function/predicate/class/whatsit and use it), so what?
Greetings,
Patrick Juola
In article <328B7F64...@cci.com> Carl Donath <c...@cci.com> writes:
>Jens Kilian wrote:
>> _Any_ programming language can be implemented by an interpreter or a compiler.
>> It just doesn't make sense to speak about "compiled languages" vs "interpreted
>> languages". I take it that you have never heard about C interpreters?
>
>This does not take into account languages (Lisp, APL) where the program
>may generate functions and execute them. A compiler could only do this
>if the compiled program included a compiler to compile and execute the
>generated-on-the-fly instructions, which is difficult and/or silly.
Difficult and/or silly perhaps, but also common.
Patrick
CHRISTOPHER ELIOT
In article <328B7F64...@cci.com>, Carl Donath <c...@cci.com> wrote:
>Jens Kilian wrote:
>> _Any_ programming language can be implemented by an interpreter or a compiler.
>> It just doesn't make sense to speak about "compiled languages" vs "interpreted
>> languages". I take it that you have never heard about C interpreters?
>
>This does not take into account languages (Lisp, APL) where the program
>may generate functions and execute them. A compiler could only do this
>if the compiled program included a compiler to compile and execute the
>generated-on-the-fly instructions, which is difficult and/or silly.
Most modern Lisp environments include a Lisp compiler precisely so
that code can be generated on the fly and compiled. It is neither
difficult nor silly, it is actually a rather common practice.
>In a phrase, "self-modifying code".
>
>--
>----------------------------------------------------------------------
>-- c...@nt.com ----- ctdo...@rpa.net ----- ctdo...@mailbox.syr.edu --
>----------------------------------------------------------------------
Jim Balter
CHRISTOPHER ELIOT wrote:
>
> In article <328B7F64...@cci.com>, Carl Donath <c...@cci.com> wrote:
> >Jens Kilian wrote:
> >> _Any_ programming language can be implemented by an interpreter or a compiler.
> >> It just doesn't make sense to speak about "compiled languages" vs "interpreted
> >> languages". I take it that you have never heard about C interpreters?
> >
> >This does not take into account languages (Lisp, APL) where the program
> >may generate functions and execute them. A compiler could only do this
> >if the compiled program included a compiler to compile and execute the
> >generated-on-the-fly instructions, which is difficult and/or silly.
>
> Most modern Lisp environments include a Lisp compiler precisely so
> that code can be generated on the fly and compiled. It is neither
> difficult nor silly, it is actually a rather common practice.
A compiler is just another component of a runtime system.
Code is just another form of data.
Eval is just another function.
Compilation is translation, interpretation is execution.
There really isn't much more worth saying, so please let this silly
thread die.
--
<J Q B>
Mukesh Prasad
Erik Naggum wrote:
[snip]
> the expression "I am only an egg" refers to Robert A. Heinlein's legendary
> "Stranger on a Strange Land". so does the word "grok", which I assume is
> even more unfamiliar to you, both as a concept and as a word. it was first
> published in 1961. at that time I was _literally_ only an egg, but that is
> not what the expression refers to.
> #\Erik
We digress a bit, but "I am only an egg" was actually an
expression of politeness and humility - concepts you apparently
haven yet to grok :-)
First you assume I don't know Lisp so you can
get away with erroneous statements, then you assume
I haven't read book xyz -- and you always
manage to pick the wrong topic. Are you
always this lucky in life too? Here is a free
hint -- embed references to Joyce's works (get a copy of
Ulysses) if you want to talk about commonly read
things that I haven't read.
/Mukesh
Mukesh Prasad
Tim Olson wrote:
[snip]
> What runtime baggage does the language LISP *require*? One might say
> "garbage collection", but that can be considered a "helper function",
> just like heap allocation via malloc() is for C.
I see garbage collection as not much more than a runtime
library. But eval, intern etc require language-processing
at run-time. This is what I was referreing to as "required
baggage". In other words, when the language-processor cannot
just do its work and go away, but may have to hide itself
in some guise or other in the generated executable.
Mukesh Prasad
Lou Steinberg wrote:
[snip]
> Can you cite any sources to back up these claims? I flatly do not believe
> them. Please tell us which "books on programming languages" you are
> referring to. Were they published within the last 20 years?
> Can you direct us to any statement in the literature by any
> programming language theorist that supports this claim?
I will have to find and look through old books,
(not being academically involved, I don't keep
them on hand) but here are some books which may have
contributed to forming my opinion:
Pratt
The Dragon Book
Mehdi and Jayajeri
In general, until your very confident challenge,
I was very sure from all my reading that
languages themselves had been categorized as interpreted
vs compiled in the past. (Hence the reason
for this thread's name -- Lisp people never
liked Lisp being called an "interpreted
language".) But I will look.
> This is complete nonsense. One of the interesting features of _all_
> interpreted implementations of Lisp, from the very first, was that
> they did not interpret a character string but rather the internal
> linked-list ("s-expression") representation. See, e.g., "Programming in
> the Interactive Environment" by Erik Sandewall, Computing Surveys,
You are, of course, correct about this. This had slipped my mind.
In any event, some amount of internal processing would
obviously be necessary -- I was primarily trying to
distinguish this from subsequent implementations using
compilations to byte-code.
Cyber Surfer
> Jens Kilian wrote:
> > _Any_ programming language can be implemented by an interpreter or a compiler.> > It just doesn't make sense to speak about "compiled languages" vs "interpreted> > languages". I take it that you have never heard about C interpreters?
>
> This does not take into account languages (Lisp, APL) where the program
> may generate functions and execute them. A compiler could only do this
> if the compiled program included a compiler to compile and execute the
> generated-on-the-fly instructions, which is difficult and/or silly.
This isn't hard to do. It's just unpopular.
> In a phrase, "self-modifying code".
In a phrase, an app that include some development tools. Err,
correct me if I'm wrong, but I do believe that there are many
apps that _do_ in fact include some form of development tool(s)!
In fact, there are APIs that support this. ActiveX allows a
programmer to very simply add a "script" language to their app,
without writing a compiler/interpreter/whatever. It's all done
inside the ActiveX classes. I don't see why this couldn't work
with native code, as the OS API supports that, too, by allowing
code to write code in memory, and then call it.
BTW, In the case of ActiveX, VBScript and JavaScript are already
available and being used. If anyone could produce Scheme or Common
Lisp classes for ActiveX scripting, then I'd be _very_ happy!
Warren Sarle
Please stop cross-posting these interminable programming threads to
irrelevant newsgroups.
--
Warren S. Sarle SAS Institute Inc. The opinions expressed here
sas...@unx.sas.com SAS Campus Drive are mine and not necessarily
(919) 677-8000 Cary, NC 27513, USA those of SAS Institute.
*** Do not send me unsolicited commercial or political email! ***
David Longley
In article <328B60...@dma.isg.mot.com>
mpr...@dma.isg.mot.com "Mukesh Prasad" writes:
> Jens Kilian wrote:
>
> > _Any_ programming language can be implemented by an interpreter or a compiler.> > It just doesn't make sense to speak about "compiled languages" vs "interpreted> > languages". I take it that you have never heard about C interpreters?
> >
>
> That's a self-consistent set of definitions, but I didn't notice
> you jumping in to say "this topic is meaningless because
> there is no such thing as an interpreted language"?
>
> If you are trying to use the term "interpreted language",
> you must go by its past usage. Tactics like switching the meaning,
> terms and subject in the middle of a discussion may be legitimate
> in certain fields, but hopefully not in a technical
> discussion on programming.
>
It's not legitimate *anywhere* except in sophistry, rhetoric and
poetry... equivocation is anathema to scientific discussion and
reliable communication in any language.
--
David Longley
Cyber Surfer
In article <328B38...@dma.isg.mot.com>
mpr...@dma.isg.mot.com "Mukesh Prasad" writes:
> The case you are talking about is no different from
> a particular C program needing to execute "ls", and
> therefore needing "ls" to be bundled with it. There
> are no intrinsic language features requiring such bundling. With
> Lisp, there are, which is the basic difference. (You
> may choose not to use those particular language features,
> but that is your own business.)
No. Full Common Lisp includes EVAL and COMPILE, etc. You don't
necessarily get these functions when the code is delivered, but
that'll depend on the _implementation_. This is the same mistake
were making earlier.
Also, not all Lisps are CL. The Scheme language doesn't include
EVAL, altho some implementations may do so. It appears that
Gambit C supports this, and this is a Scheme compiler that procuces
C source code. However, you should not make the mistake of
generalising: this is only one compiler, after all.
Some Basics has an EVAL$ function that took a string (you guessed
that, I bet) and fed it into the interpreter. Not all Basics
support this, and some of them don't compile the the code into
tokenised form and then interpret it. Visual Basic doesn't work
this way, and it would be very costly if it did, and would be
worse if it support EVAL$. On the other hand, VB apps that link
to 3 MB of libraries are not unheard of.
Generalisations are dangerous. At best, they can make you look
a fool. I'll leave the worse case as an exercise for the reader.
> Actually, nobody has been arguing along the lines of "this thread
> is meaningless, because there is no such thing as an
> 'interpreted language'." Now that, I would have
> considered honest and unbiased opinion. This argument
> is only pulled out, somehow, in _defense_ of the thread!
See PJ Brown's book for my answer. ;-) Let me know when you've
read it...
> > A programming language that is widely accepted as a Lisp dialect
> > (Scheme) not only _can_ be "batch" compiled like C, I routinely
> > use just such a compiler and get the same or better performance
> > out of it. (This is the Stalin compiler.)
>
> This thread is not about Scheme, but Lisp.
Scheme is a dialect of Lisp. It's perfectly valid to refer to
it in this thread. See the Lisp FAQ.
Cyber Surfer
In article <328B76...@dma.isg.mot.com>
mpr...@dma.isg.mot.com "Mukesh Prasad" writes:
_You're_ the one making a fool of themselves. Go away and read
some books about compiler theory - _interactive_ compiles, that
is. You seem unable to understand some very basic ideas.
Why not start with an excellent introduction, "Writing Interactive
Compilers and Interpreters". P.J. Brown, ISBN 0 471 27609 X, ISBN
0471 100722 pbk. John WIley & Sons Ltd. Please come back after
reading this fine book. _Then_ we may have something to discuss.
Meanwhile, I humbly suggest that you're trying to teach your
grandmother to suck eggs...Read Brown's book and you'll begin
to understand why.
Martin Rodgers
Enrapture Limited
Cyber Surfer
In article <328C68...@dma.isg.mot.com>
mpr...@dma.isg.mot.com "Mukesh Prasad" writes:
> First you assume I don't know Lisp so you can
> get away with erroneous statements, then you assume
This appears to be a very reasonable conclusion (not an assumption),
based on your views. Until you can demonstrate your superior knowledge
and wisdom on this subject, it should be safe to assume that your
views are based on ignorance - which we've been trying to help you
change. Of course, if you prefer to either remain ignorance, or
appear that way, then I don't know what we can do for you.
You might as well take your views to a place (newgroup? whatever?)
where they'll be better appreciated/tolerated.
> I haven't read book xyz -- and you always
> manage to pick the wrong topic. Are you
Which book was that? Are you saing that you've read SIOCP? What,
if anything, did you learn from it? Please tell us, so that we
can avoid insulting your intelligence <ahem>, and so that you
can grant us the same courtesy.
> always this lucky in life too? Here is a free
> hint -- embed references to Joyce's works (get a copy of
> Ulysses) if you want to talk about commonly read
> things that I haven't read.
So you _have_ read SIOCP? Excellent. Did you understand the last
two chapters of the book? Have you also read PJ Brown's book, and
did you understand his defintions of "compiler" and "interpreter"?
Cyber Surfer
In article <328C6C...@dma.isg.mot.com>
mpr...@dma.isg.mot.com "Mukesh Prasad" writes:
> The Dragon Book
There are a great many compiler techniques not covered by this
book. It has _nothing_ to say about compiling in an interactive
system, which could explain your confusion. "Interactive" does
_not_ mean "interpreted".
BTW, _which_ one do you mean? Compilers, Principles, Techniques,
and Tools is the later book.
> In general, until your very confident challenge,
> I was very sure from all my reading that
> languages themselves had been categorized as interpreted
> vs compiled in the past. (Hence the reason
> for this thread's name -- Lisp people never
> liked Lisp being called an "interpreted
> language".) But I will look.
I suspect that you've bee mislead by a very limited source of
information. I'm only an "ameteur" compiler writer, in the sense
that none of my compilers can be described as "industrial strength",
and yet I may easily have vastly more info on compiler techniques
than you. On one shelf alone, I have at least 6 books on language
implementation (mainly compilers, but also "interpreters" of several
kinds). Most of the books on the shelf below it include compilers
and interpreters of some kind.
Someday I'll put a list of all these books into my homepage. If I
had such a page (or more likely, set of pages), I could just recommend
that you browse it...
> > This is complete nonsense. One of the interesting features of _all_
> > interpreted implementations of Lisp, from the very first, was that
> > they did not interpret a character string but rather the internal
> > linked-list ("s-expression") representation. See, e.g., "Programming in
> > the Interactive Environment" by Erik Sandewall, Computing Surveys,
>
> You are, of course, correct about this. This had slipped my mind.
How convenient. Well, I'll give you the benefit of my doubt.
However, such mistakes don't help your credibility when making
such claims as yours. Somebody ignorant of Lisp's history might
be more easily forgiven.
> In any event, some amount of internal processing would
> obviously be necessary -- I was primarily trying to
> distinguish this from subsequent implementations using
> compilations to byte-code.
What kind of processing do you mean? Parser macros?
Cyber Surfer
In article <328C69...@dma.isg.mot.com>
mpr...@dma.isg.mot.com "Mukesh Prasad" writes:
> I see garbage collection as not much more than a runtime
> library. But eval, intern etc require language-processing
> at run-time. This is what I was referreing to as "required
> baggage". In other words, when the language-processor cannot
> just do its work and go away, but may have to hide itself
> in some guise or other in the generated executable.
<ahem> The flaw in this argument has been pointed out to you
repeatedly. EVAL is not a feature of every Lisp, just as it
isn't supported by every Basic dialect. Not all Common Lisp
compilers support EVAL at runtime. Of course, we should take
care and define exactly what we mean by runtime. Since your
definitions of certain words can wildly differ from others
here, perhaps "runtime" doesn't mean the same thing to you
as it is to me and others? How can we tell?
Erik Naggum
* Mukesh Prasad
| First you assume I don't know Lisp ...
it's an undeniable, irrefutable _fact_ that you don't know Lisp or anything
you have been saying about interpreters in this thread. the proof is in
your own articles. if you did know Lisp, you could not have said anything
of what you have said. it would be a crime of logic to conclude anything
_other_ than that you do not know what you're talking about.
#\Erik
--
Please address private replies to "erik". Mail to "nobody" is discarded.
J. A. Durieux
In article <328B38...@dma.isg.mot.com>,
Mukesh Prasad <mpr...@dma.isg.mot.com> wrote:
>This thread is not about Scheme, but Lisp.
This thread is not about cows, but mammals, right?
Ralph Silverman
Richard A. O'Keefe (o...@goanna.cs.rmit.edu.au) wrote:
: Mukesh Prasad <mpr...@dma.isg.mot.com> writes:
: >"Compiled" vs "Interpreted" are merely words
: So? Are you claiming Humpty Dumpty's privilege?
: There are important issues concerning binding time.
: >But if one has to have this distinction, Lisp should
: >fall into the "interpreted" category, since the
: >"compiled" byte-code is interpreted by sofware, not
: >the hardware.
: This is complete and utter bull-dust.
: The RUCI Lisp system I used on a DEC-10 in the early 80s compiled
: Lisp to *native* DEC-10 instructions.
: The Franz Lisp system I used on a VAX-11/780 around the same time
: compiled Lisp to *native* VAX instructions.
: The Gmabit Scheme system I use on a 680x0 Macintosh compiles
: Scheme (a dialect of Lisp) to *native* 680x0 instructions.
: The Lisp system I use on a a SPARC compiles Common Lisp
: to *native* SPARC instructions.
: Even the PSL system I used on a B6700 back in the 70s compiled
: PSL (a dialect of Lisp) to *native* B6700 instructions.
: The T system I used to use on our Encore Multimaxes compiled
: T and Scheme (dialects of Lisp) to *native* NS32k instructions.
: There are or have been *native-code* Lisp compilers for all the
: major machines, from Univac 1108s, IBM 360s, all the way up to
: Connection Machines and beyond.
: >I don't know about the Lisp
: >machines though, do they (or did they) have hardware
: >instructions corresponding one-to-one with read/eval/print?
: Why Lisp machines do you mean? CONS? CADR? LMI? Symbolics?
: Xerox (1108, 1109, 1185, ...)? The Japanese ones? The European ones?
: The plain fact of the matters is that Lisp
: - *CAN* be interpreted by fairly simple interpreters
: - *CAN* be compiled to very efficient native code on any reasonable
: modern machine
: [If you can compile a language to byte codes, you can compile it to
: native code by treating the byte codes as "macros", and running an
: optimiser over the result. This has actually been used as a route
: for developing a native code compiler.]
: --
: Mixed Member Proportional---a *great* way to vote!
: Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.
--
*********************begin r.s. response*******************
technical sophistication
of this old time programmer
is undenyable ...
and, certainly,
ideas of people like this
are of the greatest value here ...
however,
while this master has had his nose
in his terminal since the 1970s
he may have missed out on some of
the pernicious political trends
^^^^^^^^^^^^^^^^
in his poor field ...
compiled (or assembled) 'native code'
is like 'real money' ...
someone always wants to debase it ...
as though 'store coupons' were as good
as cash ...
a subtle slide of programming
from a 'native code' standard
(real programming) to an
interpreted standard is obviously
intended!!!
*********************end r.s. response*********************
Ralph Silverman
z007...@bcfreenet.seflin.lib.fl.us
Greg Heath
PLEASE REMOVE COMP.AI.NEURAL-NETS FROM THIS THREAD.
THANK YOU VERY MUCH.
Gregory E. Heath he...@ll.mit.edu The views expressed here are
M.I.T. Lincoln Lab (617) 981-2815 not necessarily shared by
Lexington, MA (617) 981-0908(FAX) M.I.T./LL or its sponsors
02173-9185, USA
Mukesh Prasad
Jeff Barnett wrote:
> Just a foolow up to the above: in a LIsp I implemented for the old
> IBM 360/370 line, eval just called the compiler, ran the native code
> produced, marked the function for garbage collect, then returned the
> values. BTW, the reason for this was that I detested the way other
> Lisp's had/enjoyed differences between compiler and eval semantics.
> Jeff Barnett
This is a good technique -- and as has been pointed out
earlier, in the modern operating systems even
this is not necessary because dynamic linking
is available on most systems, so the language
processor can simply be made available as
a dynamic library at minimal overhead. No
reason even to "run" the compiler, when
you can just call it in your own address space.
(Though, of course, this does not mean that one is free
from the obligation of making the language
processor available except in particular dialetcs...)
Mukesh Prasad
Jim Balter wrote:
> A compiler is just another component of a runtime system.
> Code is just another form of data.
> Eval is just another function.
> Compilation is translation, interpretation is execution.
This is nomenclature (as I was saying originally,) but if at
run-time you need to lex and parse the language, to me that is
interpretation.
If to you it isn't, then there is no such thing as
an "interpreted language" by your definitions, because
all the techniques used in Lisp can be applied to any
given language, as I was saying originally.
What was so difficult to understand about either of these
two very simple points?
Mukesh Prasad
Right. Well, you can talk about cows to support
a viewpoint, as long as you don't make statements
like "all mammals have four legs and two horns".
Michael Greenwald
I know I'm going to regret joining in here.
Mukesh Prasad <mpr...@dma.isg.mot.com> writes:
>This is nomenclature (as I was saying originally,) but if at
>run-time you need to lex and parse the language, to me that is
>interpretation.
Nomenclature needs to be useful.
I think the point of contention here is your use of the word "need".
It is true that most dialects of Lisp have historically provided
implementation independent ways of lexing, parsing, and compiling the
language. These are *extensions*. They do not affect the semantics
of the language, nor do they categorize the *language* (as opposed to
a given implementation) as interpreted or compiled. (Of course,
however, the presence of these extensions has had an effect on what
programs were chosen to be written in Lisp --- but let's not get
confused by sociological artifacts.)
To see what I mean, consider the following assertion (ignoring the
fact that it needs some qualifications in order to be universally
true):
Any Lisp program which "needs" to use READ, EVAL, or COMPILE has
functionality such that a translation into another language (e.g. C)
would require external calls to a parser or a
compiler. (e.g. exec'ing cc).
Now, if you can make some claims about a program that, when written in
Lisp, needs to use these extensions but, when written in C, doesn't
need to use these, *then* I'll grant you that "interpreted" is a
property of the language and not the program (or the language
implementation).
>If to you it isn't, then there is no such thing as
>an "interpreted language" by your definitions, because
>all the techniques used in Lisp can be applied to any
>given language, as I was saying originally.
>What was so difficult to understand about either of these
>two very simple points?
The fact that "Interpreted language" vs. "Compiled language" doesn't
strike me (and probably others as well) as a useful distinction. On
the other hand, knowing whether a given implementation of a language
is interpreted (for example, Sabre C) will likely give me some
expectations (e.g. performance, debugging environment) which might or
might not turn out to be true. Additionally, if you told me that a
program called out to the compiler to generate new code (or was
self-modifying, or required lexing or parsing of user input, or ...)
that *might* tell me something interesting about the program (although
to me it seems much less useful than the first case. We're always
"interpreting" user input; if it happens that the "interpreter" we use
for the input is the same as the language the program is written in,
well, that just seems like an interesting coincidence, but not
necessarily something important.)
I hope this clears up why your remarks seem difficult to understand to
some readers of this newsgroup.
(One final comment: I suppose one can argue that it is valid to
interpret "Interpreted language" as a statistical comment about the
majority of implementations of a given programming language. In the
case of Lisp, though, even then I believe that it would be incorrect
to call it an "interpreted language" since the large majority of Lisp
implementations are compiled.)
Casper H.S. Dik - Network Security Engineer
t...@apple.com (Tim Olson) writes:
>What runtime baggage does the language LISP *require*? One might say
>"garbage collection", but that can be considered a "helper function",
>just like heap allocation via malloc() is for C.
A compiled lisp program typically requires a lisp interpreter; you can
always construct programs and execute them; if need be, compile them first.
So the lisp runtime system requires a interpreter/compiler. That is not
the case for languages in which it is not possible to create and/or
manipulate executable objects.
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
Erik Naggum
* Casper H. S. Dik
| So the lisp runtime system requires a interpreter/compiler. That is not
| the case for languages in which it is not possible to create and/or
| manipulate executable objects.
first, you need to distinguish between the "runtime system" and
"libraries". the _runtime_ system does not require an interpreter or
compiler. the runtime system would include error handlers, the garbage
collector, the function that was called by and returns control to the
operating system and is responsible for setting up and tearing down all
sorts of things, etc.
second, if the program has a command language, it has an interpreter for
another language embedded, and implements a micro-EVAL all of its own.
third, if the program reads data files that have any non-trivial format, it
implements the equivalent of READ, including lots of special-purpose code
to it and lex/yacc tables.
just because the functions are _not_ called READ, EVAL or COMPILE, doesn't
mean they aren't there. a language doesn't have to have executable objects
to run code not its own. any data-driven or table-driven implementation
can be regarded as an interpreter. etc. just because you can see it by
name in one language, and not in another, doesn't mean they differ in these
important regards.
it's been said that any sufficiently large programming system contains a
Common Lisp struggling to get out.
Jim Balter
Mukesh Prasad wrote:
>
> Jim Balter wrote:
>
> > A compiler is just another component of a runtime system.
> > Code is just another form of data.
> > Eval is just another function.
> > Compilation is translation, interpretation is execution.
>
> run-time you need to lex and parse the language, to me that is
> interpretation.
>
> an "interpreted language" by your definitions, because
> all the techniques used in Lisp can be applied to any
> given language, as I was saying originally.
>
> What was so difficult to understand about either of these
> two very simple points?
The difficult thing to understand is why you are still on about this,
other than as some sort of ego gratification at the expense of these
newsgroups.
--
<J Q B>
David Longley
Now that's *ironic*..
Not long ago, you were claiming that this "distinction" was
almost a test for one's competence in computing.....
What goes around, comes around eh?
Or is this just another example of the "fragmentation" I keep
drawing your (and others') attention to (which you seem
determined to conceive as 'hypocrisy').
http://www.uni-hamburg.de/~kriminol/TS/tskr.htm
--
David Longley
Jim Balter
Oh, I "said that", did I? I'm afraid that your fragmented mental
defects make you incapable of comprehending what I say, so you should
limit yourself to direct quotation.
> What goes around, comes around eh?
>
> Or is this just another example of the "fragmentation" I keep
> drawing your (and others') attention to (which you seem
> determined to conceive as 'hypocrisy').
Longley, you are apparently too mentally defective to understand that,
since you apply your standards to others but not to yourself, you are
in *moral* error. Hypocrisy is a matter of *ethics*, which are
apparently beyond your sociopathic grasp. But if I point out that
I'm not talking science here, you will criticize me for being in a
muddle, which just further demonstrates your not-quite-sane autistic
mental defect. But that is just another example of your fragmentation,
I suppose (which can only prove your point through affirmation of the
consequent, which would only prove your point about humans having
trouble with logic through affirmation of the consequent, which ... oh,
never mind.)
--
<J Q B>
Warren Sarle
You forgot to crosspost this stupid thread to sci.bio.bovine
Paul Schlyter
In article <328C69...@dma.isg.mot.com>,
Mukesh Prasad <mpr...@dma.isg.mot.com> wrote:
> Tim Olson wrote:
> [snip]
>> What runtime baggage does the language LISP *require*? One might say
>> "garbage collection", but that can be considered a "helper function",
>> just like heap allocation via malloc() is for C.
>
> library. But eval, intern etc require language-processing
> at run-time. This is what I was referreing to as "required
> baggage". In other words, when the language-processor cannot
> just do its work and go away, but may have to hide itself
> in some guise or other in the generated executable.
requires language support as well. Consider implementing garbage
collection in a language like C -- it would be next to impossible,
because of all the dangling pointers that may remain here, there
and everywhere in the program, which must be updated automatically
if garbage collection is to be useful. But such a feat would be
impossible from a runtime library only, and even very very hard if
the compiler generated support code for this.
Thus a language with garbage collection must be much more restrictive
on pointer usage than C. LISP fits this description pretty well, since
it doesn't have pointers that the programmer is allowed to manipulate
in the LISP program.
--
----------------------------------------------------------------
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pau...@saaf.se p...@home.ausys.se pa...@inorbit.com