[armedbear-devel] RFC: Autoloading and "multi-homed symbols"
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.
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@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@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
On 1 August 2012 15:34, Blake McBride <blake@mcbride.name> wrote:
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 agree 100%. I don't think it's possible to automate that, and it's not hard at all to imagine realistic scenarios where a magical autoload will almost always fail (plugins come to mind, user code decides what to load based on some condition, if an autoload goes and loads things based on some magical scanning, trouble ensues). For abcl internals, automating things would be nice, but I wonder whether we need to help the infrastructure by providing require/provide hints, as suggested, rather than have it magically-automatic.
participants (3)
-
Blake McBride -
Erik Huelsmann -
Ville Voutilainen