Newsgroups: gnu.misc.discuss,comp.lang.tcl,comp.lang.scheme
Path: cantaloupe.srv.cs.cmu.edu!das-news.harvard.edu!news2.near.net!MathWorks.Com!europa.eng.gtefsd.com!darwin.sura.net!news.sesqui.net!uuneo.neosoft.com!nmtigw!peter
From: peter@nmti.com (Peter da Silva)
Subject: Re: What should an alternative look like? was Re: Why you should not
Message-ID: <id.14CD1.4IL@nmti.com>
Sender: peter@nmti.com (peter da silva)
Organization: Network/development platform support, NMTI
References: <366u7n$9b7@agate.berkeley.edu> <kD30sc2w165w@sytex.com>
Date: Tue, 27 Sep 1994 00:40:48 GMT
Lines: 20
Xref: glinda.oz.cs.cmu.edu gnu.misc.discuss:18316 comp.lang.tcl:19337 comp.lang.scheme:9932

In article <kD30sc2w165w@sytex.com>, Scott McLoughlin <smcl@sytex.com> wrote:
> nweaver@madrone.CS.Berkeley.EDU (Nicholas C. Weaver) writes:
> > 	Would a byte code interpreter be fast enough, or would a more
> > platform specific compiler be necessary, giving machine-code output?
> Yup. For an "extension language" skip native code. BC is plenty fast.

Hell, for an extension language BC is almost overkill. Just grovel over the
syntax tree directly in list format, taking advantage of the fast parsing you
get from Lisp-type languages, the way Lisp-1.5 on the '11 did.  that'll save
a couple of big chunks of code... for a lot of apps loading in the bytecode
interpreter is as much overhead as parsing the lists.

And it'd make implementations and porting easier, which helps spread the
system around. One thing you have to learn in the Lisp community is that
making things easy for implementors is vital.
-- 
Peter da Silva                                            `-_-'
Network Management Technology Incorporated                 'U`
1601 Industrial Blvd.     Sugar Land, TX  77478  USA
+1 713 274 5180                       "Hast Du heute schon Deinen Wolf umarmt?"
