Re: [gambit-list] Module system ELS20 presentation John Cowan (27 Apr 2020 15:38 UTC)
Re: [gambit-list] Module system ELS20 presentation Marc Nieper-Wißkirchen (27 Apr 2020 15:54 UTC)
Scheme library namespace and library name mapping Lassi Kortela (27 Apr 2020 16:03 UTC)
Re: [gambit-list] Module system ELS20 presentation Marc Feeley (27 Apr 2020 16:38 UTC)
Re: [gambit-list] Module system ELS20 presentation Peter Bex (27 Apr 2020 16:14 UTC)
Re: [gambit-list] Module system ELS20 presentation Lassi Kortela (27 Apr 2020 16:27 UTC)
Re: [gambit-list] Module system ELS20 presentation Marc Feeley (27 Apr 2020 16:52 UTC)
Re: [gambit-list] Module system ELS20 presentation Lassi Kortela (27 Apr 2020 17:02 UTC)
Re: [gambit-list] Module system ELS20 presentation Matthew Flatt (27 Apr 2020 17:07 UTC)
Re: [gambit-list] Module system ELS20 presentation Marc Feeley (27 Apr 2020 17:14 UTC)
Re: [gambit-list] Module system ELS20 presentation Lassi Kortela (27 Apr 2020 17:17 UTC)
Re: [gambit-list] Module system ELS20 presentation Lassi Kortela (27 Apr 2020 16:15 UTC)
Re: [gambit-list] Module system ELS20 presentation Marc Nieper-Wißkirchen (27 Apr 2020 16:25 UTC)
Re: [gambit-list] Module system ELS20 presentation Lassi Kortela (27 Apr 2020 16:35 UTC)
(missing)
Re: [gambit-list] Module system ELS20 presentation Lassi Kortela (27 Apr 2020 19:11 UTC)
(missing)
Eiffel Lassi Kortela (27 Apr 2020 19:43 UTC)
(missing)
Re: [gambit-list] Eiffel Lassi Kortela (27 Apr 2020 20:02 UTC)

Re: [gambit-list] Module system ELS20 presentation Lassi Kortela 27 Apr 2020 16:27 UTC

> Assuming/hoping there will at some point be a registry where one can
> download r7rs libraries (maybe there already is? snowfort?), I think it
> can be as simple as suggesting people use their library name as it occurs
> in the registry as a prefix.

Yes, snow-fort.org already has a nice collection of R7RS libraries. It
doesn't enforce any particular library name conventions.

We should set up something like lib.scheme.org that aggregates
everything. Scheme.org news coming soon.

Nevertheless, experience with golang shows that arbitrary URI imports
are still a good idea. There are so many Go packages that they cannot
hope to gather all of them in one registry, no matter how nice that
would be.

> This is lightweight, easy to understand and remember, and not as ugly or
> fraught with issues like the URI proposal.

Do you have specific issues in mind with the URIs?

>> I wonder if it's better to recommend that all URLs be enclosed in vertical
>> bars, which is safe and simple as vertical bars are not valid in URLs
>> unless %-escaped, or to specify that only URLs containing characters from
>> "#[]'(),;" be enclosed, which minimizes the use of vertical bars.
>
> That would be a problem because then you'd need an additional mapping of
> URL to filesystem location for the module.  A colon is not allowed in
> Windows file names, more than one dot might be a problem in some OSes as
> well, and slashes can't occur in file names either.  There's many more
> specifal characters:
>
> https://en.wikipedia.org/wiki/Filename#Comparison_of_filename_limitations
>
> So an e-mail address might not work either.

Good call.

I have a generic solution in mind to the filename mapping mess that
would involve having a special metadata file in the lib directory. That
file could have instructions about library lookup and compatibility,
which would then drive a small library name rewriting engine in the
Scheme implementation. By rewriting, I mean things like "assume all
library names of the form (srfi-NNN) are aliases to equivalent names of
the form (srfi NNN), and those can be found at filenames of the form
srfi/NNN.sld".