On 6/27/16 Jun 27 -10:00 AM, Ricardo wrote:
The usefulness of this feature is that it avoids having to perform manual maintenance on the system definition file every time a "plugin" is added or removed from the system. This is a pretty common thing on many projects and is easily handled by most (if not all) the system building tools I've come across in other platforms/languages.
I guess I don't see what you mean by "plugin." If a plugin is an essential part of the system, then I don't see it as a problem that you have to change the system definition file every time you add one.
I realize that make allows you to say "load all the C files," but those (as Raymond points out in a later email in this thread) are essentially independent, since the compiler translates them *and then exits* which is not the way the Lisp environment works. The lisp environment gives you a much richer context for compilation, for better or worse.
On the other hand, if the plugins are plugins like in a browser, then they should be loaded by the *user*, not the *developer*, and applying Faré's principle, the *user*, not the *developer* should choose where they go.
I'm not surprised that you found it hard to implement wild modules, since it would involve creating new components on the fly, based on a glob pattern match. I'd also point out that CL doesn't offer glob matching -- you wouldn't be able to count on :pathname "plugin-*.lisp" working reliably. Indeed, the "everything" solution that you point to on stack exchange will not work in general, since "e*.lisp" doesn't work in general.
If we overcame this problem (which would require combining regular-expressions with DIRECTORY), there are more: What class should the new components be? How do we handle updating an already-loaded system containing wild-modules? Do we expect that a second call to asdf:load-system will deal with additions and removals from the plugins directory? Note that this would require an extension to the way ASDF works -- and that the everything solution would fail here also, since there would be no way for ASDF to notice that it needs to re-evaluate the :COMPONENTS specs in the "euler" system.
As I said earlier, I'm not convinced that we have a clear specification of what wild-modules should do, and until I get such a specification, I'm not in favor of putting them in.
Indeed, unless I hear some howls of protest, I will remove wild-modules from contrib/ -- it's an "attractive nuisance" for programmers.