Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!tut.cis.ohio-state.edu!snorkelwacker!think!leander.think.com!barmar
From: barmar@leander.think.com (Barry Margolin)
Newsgroups: comp.lang.lisp
Subject: Re: Linking
Message-ID: <31669@news.Think.COM>
Date: 13 Nov 89 21:35:52 GMT
References: <5081@internal.Apple.COM> <5031@tekcrl.LABS.TEK.COM> <97923@ti-csl.csc.ti.com>
Sender: news@Think.COM
Organization: Thinking Machines Corporation, Cambridge MA
Lines: 22

In article <97923@ti-csl.csc.ti.com> gateley@m2.UUCP (John Gateley) writes:
>symbol-function is kind of bad. It means that you have to include
>all the function definition for all symbols used as data in you program.
>But, unless intern appears, all the symbols are there to be examined.

You were right about INTERN (and its brother, FIND-SYMBOL), but I don't
think SYMBOL-FUNCTION is as bad.  It's likely that if a symbol with a
function definition is used as data that its function definition is the
interesting thing about it, so those function definitions are probably not
wasting space.  CAR is probably the only exception, and only in automotive
applications.

SYMBOL-FUNCTION is no worse than FUNCALL, APPLY, or any other function that
takes a functional argument, since they can all invoke SYMBOL-FUNCTION
implicitly.

Making Lisp easy to compile into small binaries was never a goal of X3J13.
Much of what makes Lisp as great as it is goes contrary to that goal.
Barry Margolin, Thinking Machines Corp.

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