Re: The Lisp Curse

Rod Pemberton wrote:



Lol...

ISTM, that many of the ones you mentioned are labeled as OOP and
dynamic and/or interpreted.

Lisp is a simple interpreter which can be written in C, is sometimes coded
in C and emits C. I.e., it is no more powerful than C.

Lisp is sometimes a simple interpreter written in C, yes.

However, these days 'interpreters' are usually some kind of virtual
machine that executes its own instruction set. It's kind of irrelevant
to the programmer of the 'interpreted' language what the virtual machine
is written in, they don't see the underlying language at all.

One could compare this to Transmeta chips, which translate the x86
instruction set into the native VLIW instruction set. The x86
instruction set is 'no more powerful than' the VLIW instruction set,
because (in this case) the x86 instruction set is implemented in terms
of VLIW instructions. It's also quite a pointless claim to make,
because someone programming for the chip doesn't need to care what
translation is going on under the hood, except insofar as it might
impact performance.

The main benefits that C provides over other languages for writing a VM,
it seems to me, is that (a) it's quite fast, and (b) it's very portable,
as you note:


No, you can't. C's code is somewhat portable, and easily fixed to work on
the host, if not. So, it's implemented about as widely as Forth. No other
languages are implemented anywhere near as widely as those two. Assembly is
specific to one machine. Assembler doesn't usually setup variables which
can be moved between registers, stack, or memory automatically. That is a
key feature of most HLLs (not Forth apparently...).


The more impressive LISP compilers, though, tend to be written in LISP.
Once upon a time they would emit native code (e.g. MacLisp, T).

These days they do generally emit C, but this isn't because of any great
virtue of C apart from again speed and (most importantly) portability.
C is literally being used as the portable assembler of the common quip.

And C actually isn't a very suitable target for LISP and many of the
other languages. Various hacks have to be used to work around its
limitations in this area. One Haskell compiler for a while even had an
'evil mangler', a perl script which would hack the assembly outputted
by the C compiler.

(If you hack the assembly from the C compiler with Perl, are you still
writing in C?)


If it weren't for the fact that C is ubiquitous and machine
architectures vary, it probably wouldn't be used.

There are various other possibilities for portable assembly, like C--
(cminusminus.org) and the GCC LLVM. These don't have the maturity or
ubiquity of C, but they also don't have C's limitations as a compilation
target. C-- seems to have stalled indefinitely, but the LLVM seems to
be going strong. I've just read that the Glasgow Haskell Compiler is
getting faster results with the LLVM back-end than they are with either
their native-code back-end or their C back-end.


The Java VM is also used a bit like a 'portable assembly', again because
of it's ubiquity. I suppose we could claim that Java, Groovy and Scala
are all 'no more powerful than' the Java VM bytecode, but again the
claim seems a bit pointless. Does anyone seriously program in bytecode
directly other than language implementers?


-arc.








.

Relevant Pages

  • Re: How to read ADD,L as a symbol ?
    ... were lisp macros because I wanted seemless integration with lisp ... contexts of the opcode arguments, and the other is that you need to ... and denoted assembler variables. ... push the structure on to an instruction stream. ...
    (comp.lang.lisp)
  • Re: OT: sexps for other languages?
    ... Following in the tradition of early C++, this language would be ... Writting an assembler is Lisp is easy. ... You benefit immediately of Lisp macros, and can use any lisp function ... you have to streamline and sexpify the assembler instruction syntax. ...
    (comp.lang.lisp)
  • Re: Personal project, extending Scheme to OOP
    ... You don't know enough Common Lisp then! ... you must use the namespace operator: ... performance advantages (at least for an interpreter). ... with interpreted code it'll be much slower than with compiled code. ...
    (comp.lang.scheme)
  • Re: HLA question
    ... HLA is an x86 assembler. ... interpreter NEXT. ... The quantity of stack items ... Forth's dictionary, ability to compile words, Forth's inner and outer ...
    (alt.lang.asm)
  • Re: Suggested problems?
    ... A Lisp format assembler written in CL. ... I assume you mean LAP here (for other readers, ... Allegro CL used to program in LAP, ...
    (comp.lang.lisp)