Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!brl-adm!seismo!rpics!yerazuws
From: yerazuws@rpics.UUCP
Newsgroups: comp.lang.lisp
Subject: Re: Against the Tide of Common LISP
Message-ID: <778@rpics.RPI.EDU>
Date: Wed, 11-Feb-87 11:56:56 EST
Article-I.D.: rpics.778
Posted: Wed Feb 11 11:56:56 1987
Date-Received: Fri, 13-Feb-87 00:40:26 EST
References: <2565@well.UUCP>
Lines: 53
Summary: Only if you never have to grow your symbol table

In article <2565@well.UUCP>, jjacobs@well.UUCP (Jeffrey Jacobs) writes:
> 
> In <768@rpics.RPI.EDU>, Bill Yerazunis writes:
> 
> >  I know my code runs faster
> >with lexical than with dynamic.  Remember, when you scope lexically and
> >compile, you have an absolute displacement onto the stack. This is
> >a fast thing. 
> 
> >If you dynamically scope, you have to call a routine
> >to go into a hash table and find out where whatever-it-is is kept.
> >This is a not-so-fast thing for a compiled language.  On calling
> >and return, you have to fix up the hash symbol table for each and
> >every dynamically-scoped argument.  This is a very-not-fast thing
> 
> Say what???????????
> 
> The "value cell" is normally statically located at a known address!!!
> No need to perform hash table lookup at all!!!  All references are by
> address.
> 
> Access time may possibly be *faster*, i.e. MOV ADDR, dest instead of 
> MOV INDEX(SP),dest.depending on CPU architecture!

Yes- and no.  The fixed address will be fine and dandy as long
as you assume a fixed symbol table size and location.  In LISP, 
assuming a fixed size and/or location for anything is a bad idea,
because you never can be sure that the garbage collector isn't going
to sneak up behind your back and move it on you when you aren't
looking.
	
Or even worse, you gensym up a few thousand temporary symbols and
you run out of symbol table space.  OUCH!
	
The obvious cure for this is to call some sort of hashing function
and thereby circumvent the move/growth problem.
	
	
A related problem is the problem inherent in a lambda-definition. If I have

(defun foo (x)
  (setq x 3)
)
 
foo returns the value 3 but a global value of X, (if it exists) should
be unchanged!  Therefore, you have to save and restore EVERY formal
parameter (possibly to an undefined state).  This requires a lot of
instructions.... and cycles.
	
Lexical scoping gives each function a discardable copy on the stack. 
Therefore, no difficult restores.
	
	-Bill Yerazunis