Path: utzoo!censor!geac!jtsv16!uunet!wuarchive!gem.mps.ohio-state.edu!apple!apple.com!chewy
From: chewy@apple.com (Paul Snively)
Newsgroups: comp.lang.lisp
Subject: Re: LISP compiler?
Message-ID: <5131@internal.Apple.COM>
Date: 10 Nov 89 17:50:06 GMT
Distribution: usa
Organization: Apple Computer, Inc.
Lines: 30
References:<2606@bingvaxu.cc.binghamton.edu> <1325@skye.ed.ac.uk> <20585@mimsy.umd.edu> <5057@internal.Apple.COM> <4327@hplabsz.HPL.HP.COM>

In article <4327@hplabsz.HPL.HP.COM> mayer@hplabsz.HPL.HP.COM (Niels 
Mayer) writes:
> In article <5057@internal.Apple.COM> chewy@apple.com (Paul Snively) 
writes:
> >Your description of what Macintosh Allegro Common Lisp does is 
completely 
> >accurate, obviously, which is a fancy way of saying that the current 
> >version(s) of MACL don't have what amounts to a "smart linker;" that 
is, 
> >unused code from your application is NOT currently stripped out 
(although 
> >strictly development-related things like the compiler itself are).  A 
> >future version of MACL WILL do a treewalking dead-code stripper, 
reducing 
> >application sizes tremendously.
> 
> So what does MACL's fancy dead-code stripper do when your program happens
> to call 'eval' or 'apply'?

It depends upon what the arguments to either of these functions are.  For 
EVAL, I'd expect it to throw up its hands in despair, like MacScheme does. 
 Or perhaps it just needs to know if the expression can be "found" in the 
current environment (i.e. (EVAL (READ)) wouldn't work).

__________________________________________________________________________
Just because I work for Apple Computer, Inc. doesn't mean that they 
believe what I believe or vice-versa.
__________________________________________________________________________
C++ -- The language in which only friends can access your private members.
__________________________________________________________________________