Re: guile-lib things

[Rob Browning]

Andy Wingo <address@hidden> writes:

> (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.

For what it's worth, one part that I snipped from my earlier message
(just to make it more concise) basically agress with you here.  Note
that I'm not arguing against having any hierarchy, I was just noting
that I'm a bit suspicious of deep/generic module taxonomies.

I think segmentation within a given coherent sub-system, say (texinfo
html) and (texinfo parse) or (gtk canvas) and (gtk text-area), is
often a fine idea.  Similarly, I have no problem with using
sub-modules for disambiguation -- i.e. perhaps (ttn graph) and (wingo
graph) rather than (ttn-graph) and (wingo-graph), or more concretely,
say (slib format), (slib uri), and (slib posix-time), if slib were
represented directly as guile modules.

The deeper generic taxonomies also make me wonder if for many
purposes, perhaps something like a keyword based search facility would
be more appropriate -- so you can support something like (find-modules
"database" 'and "relational"), (find-modules "database" 'and
"object-oriented"), or perhaps (find-modules "database" 'and
"contact").

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4