Re: srfi names MJ Ray 14 Aug 2002 13:18 UTC
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