Email list hosting service & mailing list manager

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:35 UTC

> Do we want advertising for commercial services in library names in Scheme?
I'd leave that up to users. Is there a particular way we can restrict
it? If we have a lib.scheme.org it will hopefully be neat enough that
people will voluntarily want their libraries to have scheme.org instead
of github.com.

More generally, any large-scale distributed namespace is going to end up
with lots of messy names. I don't think there's a general way to avoid
that problem (other than not being popular enough to have mutually
unknown people coining names :)

> To encode a protocol in library names is crazy if you ask me,
> especially because the most popular protocol changes over time as you
> write.

Fully agreed.

> But without the protocol, we don't have URLs anymore.

 From Python 3:

 >>> import urllib.parse
 >>> urllib.parse.urlparse("example.com/foo")
ParseResult(scheme='', netloc='', path='example.com/foo', params='',
query='', fragment='')

So if you give it a URL without a scheme, it returns scheme='' which we
can fill in with the default.

I'm not sure what the RFCs say about such URIs, but that can be remedied
with a specification like "parse as a URI; if invalid, try prepending
https:// and parsing again". It shouldn't be hard to come up with a
practical rule.

> I guess that most R7RS systems will map the library
> `(foo.com/bar/baz)' to the same file system location as `(foo.com bar
> baz)'. To me, this shows some flaws in the approach.
>
> To use the example from above, GitHub may distribute a library
> `(github.com hacker foo)' under this proposal. Mr. Hacker owning a
> GitHub account wants to distribute `(github.com/hacker foo)'. This
> won't work without a clash.

Good point. I'd advocate for standardizing a simple rewriting and
filename mapping engine to work around problems like this (which I
believe will come up no matter what kind of practical naming scheme we
choose).