Wildcard modules support

[Robert Goldman]

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.