Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!mit-eddie!husc6!ut-sally!utah-cs!utah-orion!shebs
From: shebs@utah-orion.UUCP
Newsgroups: comp.lang.lisp
Subject: Re: autoload (was: Re: Against the Tide of Common LISP)
Message-ID: <148@utah-orion.UUCP>
Date: Tue, 17-Feb-87 12:30:39 EST
Article-I.D.: utah-ori.148
Posted: Tue Feb 17 12:30:39 1987
Date-Received: Wed, 18-Feb-87 05:57:25 EST
References: <2581@well.UUCP> <2582@well.UUCP> <4296@utah-cs.UUCP> <359@bcsaic.UUCP>
Reply-To: shebs@utah-orion.UUCP (Stanley T. Shebs)
Organization: PASS Research Group
Lines: 42

In article <359@bcsaic.UUCP> michaelm@bcsaic.UUCP (Michael Maxwell) writes:

>I'm curious: what's the disadvantage (besides the time it takes to do it)
>of autoloading?

In order to provide for autoloading of a function, you have to preload the
name of the function and the place where its code lives, i.e. a form like

(define-autoload sort "/net/fileserver/usr/lib/cl/sort.b")

or some such.  You have to have both the symbol SORT and the pathname for its
file present all the time.  This may not seem like a big deal, but consider
that CL has over 600 functions---you chew up a bit of space for all those
(tho admittedly not several megs!).  A decent autoloading system should also
be more clever than just to look at functions - consider FORMAT with strange
options, or even ordinary /.  It would be unreasonable to load Roman numeral
printing just because you happened to say (format "hi there.~%"), or to load
ratios just because / can produce them sometimes.  The observant reader will
suggest that autoloading be performed on internal functions like RATIO/ and
PRINT-ROMAN, but of course there are thousands and thousands of internal
functions.  Finally, the loading time overhead can be nontrivial---if the
implementation is highly interconnected internally, you may end up loading
most of the system the hard way anyhow (it's not implausible for INTERSECT
to call SORT, which calls MAKE-ARRAY, ...).

Of course, none of these are insurmountable problems, but they do tend
to discourage implementors from building a system based on autoloading.
It *is* a useful feature to have!

>We're using a version of Common Lisp that takes up
>something over 5 megs just for itself,

Sounds suspiciously like Lucid's system, which is unusually voluminous,
partly because the compiler is resident (now *there's* a function to
autoload!).  Many people believe that a full CL can be fit into one meg
of memory, but it requires serious attention to space optimization, which is
currently unfashionable - "just add another memory board!".  I wonder
if compiler writers ever get kickbacks from memory manufacturers... :-(

>Mike Maxwell

							stan