Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!necntc!encore!pierson
From: pierson@encore.UUCP (Dan Pierson)
Newsgroups: comp.lang.misc
Subject: Re: Icon
Message-ID: <2506@encore.UUCP>
Date: 18 Jan 88 16:51:04 GMT
References: <636@PT.CS.CMU.EDU> <6121@cisunx.UUCP> <3132@cbmvax.UUCP> <3473@megaron.arizona.edu>
Reply-To: pierson@encore.UUCP (Dan Pierson)
Organization: Encore Computer Corp, Marlboro, MA
Lines: 21

In article <3473@megaron.arizona.edu> gudeman@arizona.edu (David Gudeman) writes:
>For a good time, say that in comp.lang.lisp.  By the way, Icon's
>"interpreted" code is what Lisp people call "compiled".  That is, the
>Icon translator converts from Icon source code to a virtual machine
>code that is run by an interpreter.  Most "compiled" lisps work the
>same way.

Uhm, not quite true...

Virtual machine compilation (a.k.a. byte-code compilation) is indeed
used by many lisp and scheme systems where portablility and low
maintenance are valued more than execution speed.  GNU Emacs and MIT
CScheme are two of the most widely used examples.  Real production lisps
use real compilation.  There have been cases of Lisp compilers
successfully competing with compilers for such languages as Fortran and
C since the mid-seventies.  MacLisp, Franz Lisp, T, InterLisp, and all
Common Lisps that I know of compile to native machine code.
-- 

In real life: Dan Pierson, Encore Computer Corporation, Research
UUCP: {talcott,linus,necis,decvax,ihnp4}!encore!pierson
Internet: pierson@multimax.arpa