[armedbear-devel] RFC: Autoloading and "multi-homed symbols"

[Blake McBride]

Greetings,

I understand the problem - at least to a degree.  With user code, not part
of the boot process, I would think that I wouldn't rely too much on lisp
magically knowing what to do in complex situations (where different methods
are attached to the same generic).  Rather, I would push the problem to the
application programmer.  It is his responsibility to make sure everything
gets loaded and in the correct order.

I understand there is a different problem with the startup code to some
degree.  Off the cuff, what I would do is allow the auto-loading to work
for simple cases without anything special - as it works in simple minded
situations.  Now for the final case - the case in questions.  Rather than
make lisp autoload smarter and smarter - probably never able to make it
smart enough, and so complex no one understands it - what I would do is
require a programmer written function that explicitly specifies what gets
loaded and in what order.  Therefore, when some that isn't loaded gets
called, lisp first checks for any of these "special case" situations (which
was registered at initial boot time) and runs that if it exists.  If one of
these special case functions doesn't exist for that item a simple auto-load
algorithm is employed.

Built in ABCL functions that have complex situations can have ABCL
developer specific "special case" handling code pre-loaded.  These would
have to be maintained when necessary but should be made easy to do so.

This may be a better KISS solution than trying to make auto-load
ever-smarter.

Just some thoughts.

Blake McBride


On Wed, Aug 1, 2012 at 7:14 AM, Erik Huelsmann <ehuels at gmail.com> wrote:

> Hi all,
>
> Just committed my progress on the automatically generated autoloads. The
> next step is to clean up "autoloads.lisp" (the file which still exists to
> allow manual addition/manipulation.
>
> While I can do that step by myself, I'd like to discuss a problem we
> already have today, just never encountered:
>
> Generic functions can have methods defined in more than one file. Example:
> PRINT-OBJECT has its GF defined in print-object.lisp, but has methods
> defined in print-object.lisp, java.lisp and format.lisp. Clearly, when
> PRINT-OBJECT is being called for the first time (and hence needs to be
> autoloaded), it's not correct to autoload java.lisp or format.lisp: we
> would miss the generic function and if print-object.lisp is loaded later,
> it'll overwrite the methods already defined.
> On the other hand, *only* loading print-object.lisp isn't correct either:
> we have no idea if the arguments passed to the call should have caused the
> methods in java.lisp or format.lisp to be triggered.
>
> My current thinking about the above is that we'd need to load all files in
> which methods are being defined for PRINT-OBJECT. These files should makes
> sure (through REQUIRE) that they load the file with the generic function
> first. The autoloading facility should then hook into require in some way
> or another to make sure it doesn't load files which have been loaded
> through REQUIRE to prevent out-of-order loading.
>
> Then my next issue is that if one of the files being loaded in the loaded
> group has symbols which are multi-homed in a different (but overlapping)
> set of files, those files need to be loaded as well, for the same reasons.
>
>
> My question is: what are your thoughts on the subject?
>
> BTW: I have some more questions I'd like to discuss regarding autoloading,
> but since they are unrelated, I'm holding off posting until discussion on
> this subject has settled on a general direction for development.
>
>
> What was autoloading again? Autoloading is a mechanism which allows ABCL
> to start up quickly by deferring loading of FASLs which it only needs
> later. Also, helps ABCL to run in memory-restrained environments by loading
> only the support necessary to run the code at hand. Autoloading is a
> feature used *only* for ABCL's own FASLs. User-FASLs will always be fully
> loaded (although I suppose it should be possible to leverage the existing
> autoloader infrastructure to help users who think they need this for
> themselves).
>
>
> Bye,
>
> Erik.
>
> _______________________________________________
> armedbear-devel mailing list
> armedbear-devel at common-lisp.net
> http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/armedbear-devel/attachments/20120801/754b87e8/attachment.html>