This page is part of the web mail archives of SRFI discuss from before July 7th, 2015. The new archives for SRFI discuss contain all messages, not just those from before July 7th, 2015.
Alex Shinn <foof@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