Email list hosting service & mailing list manager

Re: srfi names Alex Shinn 14 Aug 2002 11:00 UTC

>>>>> "MJ" == MJ Ray <> writes:

    MJ> Alex Shinn <> wrote:
    >> [ cc'ing which is a better place
    >> for this discussion ]

    MJ> well as where?


    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.