Re: srfi names Alex Shinn 14 Aug 2002 11:00 UTC
>>>>> "MJ" == MJ Ray <xxxxxx@cloaked.freeserve.co.uk> writes: MJ> Alex Shinn <xxxxxx@synthcode.com> wrote: >> [ cc'ing xxxxxx@srfi.schemers.org which is a better place >> for this discussion ] MJ> ...as well as where? c.l.s Ben> Elsewhere, I see an overall consensus: We Need Modules. >> Most definitely. That is probably the single biggest problem >> facing Scheme right now... until we get a module system, the >> average Scheme script will never work on more than one Scheme, no >> matter how similar the Schemes in question. MJ> I'm not so sure. Modules are nice (they beat load at least), MJ> but which of the many different implementations of modules do MJ> you pick to standardise on? Do you try to standardise a naming MJ> convention too? There you hit the thorns and it's not a fatal MJ> flaw, so a lot of people seem to ignore it. Seem to ignore the lack of a module system? No, they just create their own, incompatible ones. Yes, a module SRFI is very difficult, but the lack of one is still a problem. 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. Exact syntax can be left open... the syntax as used in a module system may be prefix.module or prefix::module or even (prefix module), but somehow we're going to need to agree on the hierachy and ambiguity resolution. Choose a form to list in the registry, and if it conflicts with a specific module system that system is free to perform the obvious name translation. >> It limits our ability to share code - anything from one Scheme >> always requires munging to work with another MJ> Editing the start of the script (which you'll need to do anyway MJ> to change the interpreter &c, most likely) isn't really mashing MJ> until no good. Maybe a poor word choice on my part... is "munging" mashing until no good? 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... Just pointing out this isn't something you have to do in any other language I've programmed in. You still have porting issues, but you don't have to start out the process by editing every single file because one implementation uses #include while another uses !include. >> Yet another option is to do what CPAN does (I don't know of any >> other public code repository as large or successful) [...] MJ> How are you defining success? To me, CPAN tends to look rather MJ> like the librarians were asleep while stock intake occurred. If MJ> we can avoid that problem, we will have done well. 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. But they did pretty well with the names for not having any formal naming convention. And it's far from perfect but is infinitely superior to 3584 numbers. So I'd say it deserves consideration as one of the valid naming systems we could use. -- Alex