Newsgroups: comp.lang.lisp
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!hellgate.utah.edu!cdr.utah.edu!moore
From: moore%cdr.utah.edu@cs.utah.edu (Tim Moore)
Subject: Re: LISP compiler?
Date: 10 Nov 89 15:49:42 MST
Message-ID: <1989Nov10.154943.18376@hellgate.utah.edu>
Organization: University of Utah CS Dept
References: <5081@internal.Apple.COM> <5031@tekcrl.LABS.TEK.COM> <Nov.10.13.33.46.1989.3812@bearcat.rutgers.edu> <5140@internal.Apple.COM>

In article <5140@internal.Apple.COM> chewy@apple.com (Paul Snively) writes:
>I'm not sure that the example of passing a LAMBDA expression to APPLY is 
>valid; there's nothing whatsoever to prevent LAMBDA expressions from being 
>compiled (I'm pretty sure that LAMBDA expressions in MACL are compiled, at 
>any rate).

The problem is that the argument to APPLY and FUNCALL is a lambda
expression, which can be an arbitrary list, consed up at runtime. With
the appropriate use of THE, you could specify that this would never
happen, or the compiler might be able to figure that out itself
through data flow analysis. Good luck with the general case.

This is another example of why saying 
'(lambda (foo bar) (list foo bar)) 
when you mean
#'(lambda (foo bar) (list foo bar))
is bad; the compiler can't do anything with the former (not to mention
lexical scoping issues.)
Tim Moore                     moore@cs.utah.edu {bellcore,hplabs}!utah-cs!moore
"Ah, youth. Ah, statute of limitations."
		-John Waters
