Alex Shinn <xxxxxx@synthcode.com> wrote:
>    MJ> ...as well as where?
> c.l.s

OK.  If you CC a mailing list, I lose the original newsgroup header.  Most
clients I've seen put "this is a cc of a message posted to foo.bar".

> Seem to ignore the lack of a module system?  No, they just create their
> own, incompatible ones.  [...]

Nevertheless, they ignore the lack of a standard module system.  Not all
make their own systems.  Please: we're not writing a standard yet, so let's
leave the language lawyer replies aside.

> [...] I hope to see such a SRFI someday, but in the meantime (and almost
> precluding that SRFI) is coming up with a decent naming convention.

Wishing won't make it so, as I'm always being told about SRFIs.  I guess
we're taking the first steps here, but someone needs to step up to the plate
and start condensing past and present discussions and implementations of
modules into a SRFI.

Here's a question that bugs me about SRFIs in general: what state does a
proposal need to be in before being submitted to the SRFI process?
Generally, it seems to be a preliminary discussion on cls and elsewhere, but
how much initial storm should you be willing to continue through?

> [...] is "munging" mashing until no good?

; dict mung
[...]
>From The Free On-line Dictionary of Computing (09 FEB 02) [foldoc]:

  mung

     /muhng/ (MIT, 1960) Mash Until No Good.

     Sometime after that the derivation from the {recursive
     acronym} "Mung Until No Good" became standard.
[...]

> I don't know, it just seems like an incredible pain to even have to edit
> the code.  Then do so for every file, for every update, for every Scheme
> you use, for every machine...

I had the same task in Forth.  I don't know what the current standardisation
of Forth is like, though, but claiming FIG-Forth support wasn't enough.

> Success in managing 3584 module names, and having those names mostly
> make sense and be easy to use.  Success in a very convenient online
> search mechanism and automated installation using those names.  This is
> not claiming anything about the quality of the modules, or the module
> system or even the language.  [...]

I think maybe here is the problem: you are trying to solve a different
problem to SRFI.  SRFIs are more like PEPs (Python) or RCRs (Ruby) than
CPAN.  I'm not sure Perl has such a mechanism, but I don't follow its
development much any more.

If you want to build a module library like CPAN, I'd suggest starting by
SRFIing the things you need (eg modules) and deciding your own module name
to SRFI number mapping system for when a module implements a SRFI.  I don't
think making SRFI into CPAN will be a good move.  It possibly won't even
work properly.

MJR