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)
|
> 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".