Re: Naming modules (was: Re: getop-gnu-style.scm)

[Maciej Stachowiak <mstachow@mit.edu>]

gord@trick.fig.org writes:
> Hi!
> 
> >>>>> Maciej Stachowiak writes:
> 
>  MS> 1) Modules that come with the Guile core.
> [...]
>  MS> * (guile ...) for modules from category 1 which do not fit well
>  MS> anywhere in the category 2 hierarchy.
> 
> Why not (lib guile ...)?
> 

I see things that ship with Guile as an entirely separate
category. Basically these fall into "provided parts of the
interpreter". Some of these will probably be implemented in libguile
itself, not in shipped code. For example, there should probably be a
(guile) module which provides the default Guile exported bindings
(IMO: R5RS plus the module system), (guile r5rs) which provides a
totally stock r5rs environment, (guile safe) which provides r5rs minus
anything "dangerous", and so on. I see the repl as being in the same
category.


>  MS> The repl would be a good example of this.
> 
> Yes and no.  It is not hard to generalize the repl so that it is
> useful to other programs besides the default `guile' binary.  In fact,
> this is what Gush is already doing.  I've put this work into (lang
> repl), though I could easily move it somewhere else....
> 

Maybe that is logical. I wasn't thinking that the stock guile repl is
only useful to Guile, I've just been thinking of it as "part of the
interpreter" and doesn't fit in any other category very well. (lang
...) might be a good place, but I thought that was reserved specificly
for transaltors for other, non-Scheme languages. Of course, if your
repl handles multiple languages, it probably belongs in (lang ...)
someday.

>  MS> * (lib <library name> ...) for externally developed
>  MS> libraries/comprehensive packages which are not guile-specific and
>  MS> have their own organization. [...]
> 
>  MS> * (app <application name> ...) for modules that come with an
>  MS> application and only make sense in the context of that
>  MS> application. [...]
> 
> I don't know if it is useful to distinguish between these two.  My
> personal preference would be just to use (lib gush ...), and leave it
> at that.  Then, as people decide that a given module is useful to more
> than just Gush, we would move it out into the by-function namespace.
> 

I was thinking, for the (app ...) namespace, more of things like scwm
or siag which are much more clearly applications than libraries. It is
my impression that GUSH blurs this distinction somewhat. Perhaps GUSH
modules would belong in (lib gush ...) rather than (app gush ...)
under my proposal.

> 
> Yes, absolutely.  Gush is less of an application program, and more of
> an evolving framework for how syntax translators could be implemented.
> 

Way cool.

>  JB> You'd also like your naming system to give some confidence that
>  JB> module names won't change often.  I guess the project-name-prefix
>  JB> approach is okay in this regard.
> 
> It doesn't matter how often module names change if their interfaces
> are still changing.  This puts us smack dab in the middle of another
> can of worms: interface versioning.

Jim's theory on this seems to be that no interface versioning system
is good enough to be worth the bother, and I find his arguments fairly
compelling. (Sorry if I am oversimplifying or misrepresenting your
views, Jim.)


Any thoughts on my CPAN-like repository suggestion?

 - Maciej