From: Rob Browning <rlb@defaultvalue.org>
Cc: Guile Users <guile-user@gnu.org>
Subject: Re: guile-lib things
Date: Wed, 30 Jun 2004 17:20:46 -0500 [thread overview]
Message-ID: <873c4csn5t.fsf@trouble.defaultvalue.org> (raw)
In-Reply-To: <1088531031.1484.94.camel@localhost> (Andy Wingo's message of "Tue, 29 Jun 2004 18:43:51 +0100")
Andy Wingo <wingo@pobox.com> 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
_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user
next prev parent reply other threads:[~2004-06-30 22:20 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-06-24 18:03 guile-lib things Andy Wingo
2004-06-25 11:48 ` Andy Wingo
2004-06-25 18:31 ` Rob Browning
2004-06-27 21:43 ` Linas Vepstas
2004-06-29 17:43 ` Andy Wingo
2004-06-30 22:20 ` Rob Browning [this message]
2004-07-08 19:01 ` Andy Wingo
2004-07-03 16:48 ` Thien-Thi Nguyen
2004-07-10 4:44 ` Linas Vepstas
2004-06-27 1:22 ` ASDF for guile (Was Re: guile-lib things) Chris Hall
2004-06-28 13:33 ` Matthew Trout
2004-06-28 13:48 ` Andy Wingo
2004-07-01 21:42 ` guile-lib things Neil Jerram
2004-07-08 19:09 ` Andy Wingo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=873c4csn5t.fsf@trouble.defaultvalue.org \
--to=rlb@defaultvalue.org \
--cc=guile-user@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).