Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!think!leander.think.com!barmar
From: barmar@leander.think.com (Barry Margolin)
Newsgroups: comp.lang.lisp
Subject: Re: LISP compiler?
Message-ID: <31645@news.Think.COM>
Date: 11 Nov 89 00:50:51 GMT
References: <5081@internal.Apple.COM> <5031@tekcrl.LABS.TEK.COM> <Nov.10.13.33.46.1989.3812@bearcat.rutgers.edu> <5140@internal.Apple.COM> <1989Nov10.154943.18376@hellgate.utah.edu>
Sender: news@Think.COM
Organization: Thinking Machines Corporation, Cambridge MA
Lines: 23

In article <1989Nov10.154943.18376@hellgate.utah.edu> moore%cdr.utah.edu@cs.utah.edu (Tim Moore) writes:
>The problem is that the argument to APPLY and FUNCALL is a lambda
>expression, which can be an arbitrary list, consed up at runtime.

This particular feature is being taken out of ANSI Common Lisp.  The
definition of the FUNCTION data type is being tightened, and it will refer
to a specific, distinguishable data type.  The FUNCTION special form and
the SYMBOL-FUNCTION function will be guaranteed to return objects of this
type.  Functions that take functional arguments will accept either a
function or a symbol (automatically calling SYMBOL-FUNCTION on the latter);
they will no longer take lambda lists.  Lambda lists will be coercible to
functions with (COERCE <lambda exp> 'FUNCTION); this is defined to be
equivalent to (EVAL '(FUNCTION <lambda exp>)).

So, returning to the issue of the code walker that removes unnecessary
runtime functions, APPLY, FUNCALL, MAP, etc. will not force inclusion of
everything.  EVAL and COMPILE definitely will, and COERCE may if its second
argument is non-constant or the symbol FUNCTION.  READ also may force
inclusion of everything, unless you've disabled "#.".
Barry Margolin, Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar