NetNews Usenet Archive 1993 #3/NN_1993_3.iso/spool/comp/lang/lisp/3412

Internet Message Format | 1993-01-28 | 3.6 KB

Path: sparky!uunet!europa.eng.gtefsd.com!gatech!darwin.sura.net!newsserver.jvnc.net!yale.edu!ira.uka.de!math.fu-berlin.de!news.netmbx.de!Germany.EU.net!mcsun!julienas!corton!ilog!davis
From: [e-mail] (Harley Davis)
Newsgroups: comp.lang.lisp
Subject: Re: Lisp syntax beauty? (was Re: Why Isn't Lisp a Mainstream Language?)
Message-ID: <[e-mail]>
Date: 28 Jan 93 17:53:47 GMT
References: <dfs.727732459@kehleyr>> <[e-mail]>
    <dfs.727757157@kehleyr> <[e-mail]>
Sender: [e-mail]
Organization: ILOG S.A., Gentilly, France
Lines: 62
In-reply-to: [e-mail]'s message of 27 Jan 93 13:32:00 GMT


In article <[e-mail]> [e-mail] (Jeff Dalton) writes:

   >Absolutely.  But if you don't want to use a certain C function, you don't
   >link it in.  Your programs have no overhead for unused functionality.
   >If Common Lisp had some mechanism for this, then my criticism would not
   >be valid.

   The C language has no mechanism for this.  It's the linkers that do
   it.

   So, the right question is: is there something about the language
   that rules out implementation strategies that omit unneeded code?
   And the answer is "yes".  Almost anything could be called, eg by

      (apply (read) (read))

   So implementation either have to provide a way for the user to
   say that only the functions that are directly called will be
   called or else provide a way to load in functions when needed.
   The latter approach has been around for a long time in the
   form of "autoloading".

   However, such tricks won't work very well if programs tend to
   require most of CL, perhaps because CL is so intertwined.  This
   is a standard criticism of CL.  ERROR requires FORMAT, etc.
   But how true is it?  Well, I think there's evidence that it's
   sufficiently true to be a problem.  On the other hand, why
   should it be fatal.  What if, for instance, CL is packaged as
   a shared library (as in WCL)?  It's a fairly big shared library,
   but then so is X.

The problem is somewhat more complex.  Another difference between Lisp
and C is that Lisp allows the creation of rather complex data at the
top-level.  These data objects range from symbols to functions to data
structures stored in global variables to classes, etc.  Although
shared libraries help a lot in managing code size, they do not reduce
data requirements.  Even modules which have completely unexecuted code
still need to initialize their data; at a minimum, their symbols and
most likely a number of functional objects as well.  There may be ways
to put off the creation of other top-level data until the module is
needed, but this requires rather complex management which has its own
cost.  All this said, shared libraries are still winning.  However, it
would probably be a mistake to provide *all* of Lisp as one shared
library.

I should note that C++ also has this problem to some extent since it
allows top-level data initialization and needs to initialize its
virtual function tables and other class-related hidden objects.  In
fact, I don't think many C++ compilers allow the creation of shared
libraries.  For example, Sun C++ has no position independent code
generation option.  This may be seen as one of the biggest changes
between C and C++, and has many ominous overtones that most of C++'s
advocates don't yet understand.

-- Harley Davis
--

------------------------------------------------------------------------------
nom: Harley Davis            ILOG S.A.
net: [e-mail]            2 Avenue Gallie'ni, BP 85
tel: [phone]            94253 Gentilly Cedex, France