Re: guile-lib things

[Andy Wingo]

Hey folks,

Ya'll have made me nearly reverse my position, FBOFW :P

On Sun, 2004-06-27 at 16:43 -0500, Linas Vepstas wrote:
> On Fri, Jun 25, 2004 at 01:31:29PM -0500, Rob Browning was heard to remark:
> > Andy Wingo <address@hidden> writes:
> > 
> > > [0] At one point, I wanted strictly taxonomic names for the
> > > modules.
> >
> >   That said, I tend to prefer flatter namespaces for modules when
> >   there's a choice.  For example, modules like (text regexp pcre), (db
> >   relational sql postgresql), or even (graphics opengl) seem
> >   unnecessary and even potentially confusing to me.
> 
> Yes!  Deep taxonomies also hinder authors who are working on
> new stuff, which tends to cross boundaries: if it could be easily
> classified, it would be a whole lot more boring, and maybe not
> worth doing ....  For example, suppose you had to classify a blog 
> tool, say 5 years ago.  What category would you have put it then?  
> Is slashdot a blog or a news agregator?  Who knows? 

This strikes me two ways:

One, that the examples you give are examples of applications, not of
library routines. Modules == library routines, syntax, hooks, etc. Most
larger applications will have modules, of course, but that's separate --
those modules would be part of the app, not part of a library.

The second way this strikes me is that many guile programmers want flat
hierarchies. Your statement has been echoed quite a bit in the past. At
the risk of resurrecting horses only to beat them yet again, I'd make
some assertions:

1) There is a place for hierarchy in modules.

I take as evidence:

(a) Packages can have pieces. In my case, I built a texinfo processing
framework. There's a parser, an html transformer, a plain-text
transformer, etc etc etc. (texinfo-parse), (texinfo-to-html), etc are
manifestly stupid names, and moreover hierarchy is encoded in their
names already.

(b) Routines might be small enough that they don't have a package
identity. Most things in ice-9 are that way. Modules in ice-9 would
benefit from some kind of classification. (Is this true?)

2) Deep taxonomic hierarchies are too rigid.

Evidence again:

(a) Hierarchy doesn't appear in python or perl modules, except in the
case that all modules are part of the same package, or extend a common
package. Same in C (flat library namespace), same in Debian (flat
package namespace). If packages are classified, it's only for
presentation and not in ways that matter.

Corollary: taxonomic hierarchies in guile-lib as it stands indicate that
it considers itself to be the package, and is thus not, in its current
form, a suitable distribution mechanism for third-party code.

(b) Classifications change.


So, if guile-lib wants to be a distribution point (through a centralized
mechanism or otherwise), it should adopt a flat module hierarchy. If, on
the other hand, it views itself as a single package, then the answer is
less clear. This case is closer to slib, whose documentation is ordered
taxonomically, but whose require namespace is flat.

I guess this really comes down to the question, "What is guile-lib?" Is
it a distribution point, or is it an slib? (Although slib suffers a
similar dilemma: a debugger, for example, surely has an identity as a
package, not just some routines.) What is the virtue of another slib?
Should guile-lib take things from slib, just because it's easier for
guile (think modules, insulation against slib changes)? If it is in fact
an slib, should it have a (lib ...) prefix, as would be suggested by the
guile-lib name? Is it just another ice-9, but perhaps one whose
development hasn't calcified?

I've been a bit schitzophrenic about the answer to that question lately.
In the end, guile-lib is what people make it, so input from all is
welcome to make it a resource of maximum utility. I'm still ruminating
my answer to that, perhaps more later in the week.

Cheers,
-- 
Andy Wingo <address@hidden>