Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!caip!ut-sally!utah-cs!utah-orion!shebs
From: shebs@utah-orion.UUCP (Stanley Shebs)
Newsgroups: net.lang.lisp
Subject: Re: Against the Tide of Common LISP
Message-ID: <134@utah-orion.UUCP>
Date: Wed, 2-Jul-86 12:03:35 EDT
Article-I.D.: utah-ori.134
Posted: Wed Jul  2 12:03:35 1986
Date-Received: Thu, 3-Jul-86 06:56:23 EDT
References: <1311@well.UUCP> <3827@utah-cs.UUCP> <1316@well.UUCP> <3837@utah-c <1372@well.UUCP>
Reply-To: shebs@utah-orion.UUCP (Stanley Shebs)
Organization: University of Utah CS Dept
Lines: 52

In article <1372@well.UUCP> jjacobs@well.UUCP (Jeffrey Jacobs) writes:

>>Ah, we're talking about the interpreter again.  I still don't understand why
>>anyone would think interpreter performance would matter - the overhead
>>is so tremendous already that dynamic/lexical lookups aren't necessarily
>>significant.
>
>It is VERY significant.  Variable reference is certainly the most frequent
>operation in LISP (CL or RL).

The most frequent operation in the interpreter is to go through the
dispatch loop deciding whether to do variable lookups or macro expansion
or function application or hook functions or whatever other feature
the implementors decided was handy.  Variable lookup may be the most
common case, but even lexical lookup is likely to be cheaper than
function application.  I don't recall seeing any thorough studies of
the real costs in an interpreter; although when one gets a 20-to-1
or better speedup using a compiler, it's easy to see why some systems
rely on an incremental compiler instead!

>That's great, but not everybody in the world is going to have a compiler
>beater handy.  (And I would certainly like to see your system).

The nice thing about compiler beating is that it only needs to be done
once, and the optimizations are available forever after.  If you want
a copy of PCLS, send your USnail address to cruse@utah-20 to get the forms.
We also have a paper on PCLS that was unfortunately not accepted for the
Lisp conference - it shows the severe hacks our compiler does to transform
Common Lisp into efficient PSL.

>>Spice is good code.  You could do a lot worse, especially if
>>you don't pay attention to the specification.
>
>Do you mean the Steele specification?  If so, and they don't meet it,
>aren't they "broken", i.e. non-portable and non-CL?

Sorry to be confusing.  What I meant was that there are a number of
subtle aspects of the language that an unwary implementor can get caught
by.  Such things include error and default handling in the package system,
argument list binding and declarations, the user hooks for SETF, and
many other things.  These things are complex for the implementor so that
the language user has an easier time with the language - there's no
sillinesses with installing magic properties on symbols, etc.  When we left
out some of these details in versions of PCLS, you can bet we heard from
the users!  Spice Lisp is the model implementation.  There are a few boners
here and there, but it goes to a lot of trouble to get details right.
Every Common Lisp implementor should study Spice Lisp code, whether or
not s/he actually uses any of it directly.  PCLS on the other hand is
quick and dirty, and invalid programs will get the most mystifying of
error messages, since we go for speed!

							stan