Email list hosting service & mailing list manager

five problems with this draft SRFI William D Clinger (26 Sep 2009 01:20 UTC)
Re: five problems with this draft SRFI Abdulaziz Ghuloum (26 Sep 2009 05:58 UTC)
Re: five problems with this draft SRFI Derick Eddington (26 Sep 2009 15:42 UTC)
Re: five problems with this draft SRFI Derick Eddington (27 Sep 2009 02:43 UTC)
Re: five problems with this draft SRFI Shiro Kawai (27 Sep 2009 03:16 UTC)
Re: five problems with this draft SRFI Derick Eddington (29 Sep 2009 02:32 UTC)
Re: five problems with this draft SRFI William D Clinger (30 Sep 2009 01:49 UTC)
Re: five problems with this draft SRFI Derick Eddington (30 Sep 2009 03:22 UTC)
Re: five problems with this draft SRFI Derick Eddington (30 Sep 2009 03:51 UTC)
Re: five problems with this draft SRFI Derick Eddington (30 Sep 2009 06:33 UTC)
Re: five problems with this draft SRFI William D Clinger (30 Sep 2009 13:11 UTC)
Re: five problems with this draft SRFI Derick Eddington (01 Oct 2009 09:10 UTC)

Re: five problems with this draft SRFI William D Clinger 30 Sep 2009 13:11 UTC

Derick Eddington wrote:
> Library references, in the current draft SRFI,
> always do have a one-to-infinite mapping to file names, because an R6RS
> version reference, including an empty/non-existent one, always matches
> versions with more components than in the version reference, and the
> possibilities are infinite.

I appreciate the clarification.

As I predicted in a message sent to r6rs-discuss before
the ratification vote (but am too lazy to look up right
now), the version number is being treated as part of the
library	name, but with special rules that add complexity
to both the semantics as seen by programmers and to
implementations.

The mapping from library references to file names is
one-to-infinite, but this draft SRFI still contains
design decisions and rationales that are based upon
the utility of one-to-one mappings between library
names and file names.

I maintain that the one-to-one mapping doesn't really
exist given the realities of this draft SRFI, from
which I conclude that the design decisions and rationales
based on that nonexistent mapping should be reconsidered.

Will