Re: naming modules

[Maciej Stachowiak <mstachow@mit.edu>]

ttn@mingle.glug.org writes:
> Jim Blandy writes:
> 
>  > (Hoping to resurrect a promising topic...)
>  >
>  > [namespace registry and possible hierarchy]
> 
> I would prefer not to have a registry because of its huge potential for
> bit-rot and goes-in-two-places problems.

Please clarify what you mean by these. Regarding the bitrot, do you
mean bitrot of the modules themselves, or of the registry? The authors
and the registry maintainer would be highly motivated to avoid the
latter; CPAN certainly seems rather non-bitrotted.

>  However, the `(lib ...)' part
> of the proposal is insightful; everyone usually produces a "library" w/
> specific (and most likely disparate) organizational requirements.  So
> why not just use the natural namespace partitioning mechanism (who you
> are, ie domain)?  

Because we want to encourage people to view contributed modules as
parts of the Guile library as a whole, and think about how they fit
into that framework. Or at least I do. I don't want to have to
understand the organizing principles of 50 libraries just to use small
bits of code from their overlapping sets of functionality, I want a
bunch of well thought out modules containing useful features that I
can cross-leverage. I want /usr/share/guile to be like /usr/lib on a
GNU/Linux box, but hierarchical. People who want to use modules for a
different purpose can put them in (chaos ..) (or maybe we can call
this (site ...) to sound less derogatory?).

> I'd agree that a module name like `(org gnu foo bar
> baz)' would be heinous, but it is unambiguous, and that is really useful
> for this problem.  Just requires some Emacs support to save typing.  

Oh really? What about a big corporation with multiple
rarely-communicating engineering groups? And what domain would I use
for modules I write? I'm not at gnu.org, I'm no longer affiliated with
MIT, although my account is here, and I can't hack free software on my
company account, so that is right out. If we go with the view that
anyone can put stuff in gnu.org, we still need a registry for that at
least.


> Or, more realistically, people will name their modules whatever they
> want, which brings up the remapping requirement...

For perl, the carrot of increased popularity by being in CPAN is
enough to convince people that they want to follow the naming
conventions. In our case, they can always escape to (chaos ...).


> Remapping is very useful, w/ per-symbol remapping the best.  I am
> thinking: many packages have some symbol called "open" or "find" or some
> other generic operation name.  Someone suggested the `(import X as Y)'
> syntax, which can be seen as a re-export (see below for a definition).
> 

Renaming imports of variables. are of course useful (e.g. both posix
and Tk have a `raise'), but are, I think an orthogonal issue.

> (define-module (X) :use-module (Y))	; w/ X "succinct" and Y "verbose"
> (reexport-from-module '(Y))		; so now using X means using Y
> 
> Anyway, a remapping might look like:
> 
> (consider-module (org gnu foo bar baz)		; unspecified means dir
> ect
>                  '((open . bazically-open)	;  import (like :use-module)
>                    (find . bazically-locate)))
> (bazically-open (bazically-find "~/.guile"))
> 
> Perhaps Per Bothner would omit the "org" and start w/ "gnu", but that's
> why remapping is useful; the user can choose another view based on other
> requirements.
> 

But there needs to be a maximally useful canonical view so that people
can write portable code that depends on modules.

> The last argument I would advance for not having a central registry
> would be the body of extant code that defies neat classification.  Hmm,
> I suppose this is just the first argument repeated for old code.

What code defies classification that would be useful to put in a
module? Ignoring for the moment multi-module packages like slib or
scsh which

> In summary, it seems that the nature of glue is more emulsifier than
> crystal, especially if there is a lot of glue involved.  I advocate
> support for arbitrary "views" over registration of one "view".  The
> latter (unfortunately) turns me off big time. :-(

Maybe it is nice to let users rename modules to organize the hierarchy
any way they like, but there needs to be a canonical hierarchy so that
(a) people can ship modules that don't need hand-configuration, and
(b) people can ship code that depends on modules but is portable. The
ways to define a canonical hierarchy are: (1) have a central registry
(works really well for perl) (2) name by domain name or project
(totally ignored in most cases for Java and therefore useless - even
Sun names their non-core classes sun.*, not com.sun.*) or (3)


I guess it comes down to what you think the purpose of the module
system is - to organize your own code, or to let different pieces of
code interdepend portably. On the grand scale of things, I think the
latter is at least a very important part of the purpose. I think a
registry is needed for this to work well. However, people who hate the
registry will not be beaten with a stick to ignore it, and are even
explicitly given a piece of the module hierarchy to play in as they
will.

> 
> ----------------------
> ;; Here is a definition for `reexport-from-module' that is used in THUD.
> (define (reexport-from-module other-module-name)
>   (let ((cur-mod   (current-module))
> 	(other-mod (resolve-module other-module-name)))
>     (for-each (lambda (name)
> 		(module-add! (module-public-interface cur-mod)
> 			     name
> 			     (module-variable cur-mod name)))
> 	      (module-map (lambda (sym x)
> 			    sym)
> 			  (module-public-interface other-mod)))))


Looks useful. I hope the next-generation module system can nicely
handle things like re-exporting part or all of another module, and
renaming symbols on import, out the box.

 - Maciej