Re: Scheme RFCs

[Marc Feeley <feeley@iro.umontreal.ca>]

> It is beyond the scope of the current discussion, but I certainly hope we
> will discourage the practice of naming features directly after Scheme RFC
> numbers.  I can exhibit examples from the Internet RFCs where it turned out
> to be a bad idea to use a name for something like "RFC1213".  The problem
> is what happens when you issue a new RFC that describes a better version of
> the same thing.  Better to use descriptive names and some kind of version
> numbering scheme.  But we should save this issue for when we get to
> discussing the RFC for `require' -- sometime soon I hope.

In my proposal for the "if-implements" construct I allow the
feature-identifier to be the name of the SRFI, e.g. SRFI-123, or an
alias that is specified with the SRFI, such as Unicode-IO.  Thus an
alias field should be added to the SRFI document format.

SRFI numbers are not human friendly but they are precise and
unambiguous.  Human friendly identifiers also don't support well
SRFI's of a similar nature (what should a new version of Unicode-IO be
called?  Unicode-IO2?  Revised-Unicode-IO?)  Maybe we should require
SRFI aliases to have a version number, such as Unicode-IO-v1.  The
problem I see with this is that if someone comes up with a wildly
different way of doing Unicode IO, then calling it Unicode-IO-v2 will
be misleading because there isn't even a mild guarantee of
compatibility between the two.

I also see a problem with polution of the SRFI alias namespace (I
don't mind that the SRFI number namespace gets poluted).  One way to
avoid SRFI alias namespace polution is to postpone the attribution of
an alias until a particular SRFI has been widely accepted by
implementors for a certain type of feature.  We would need to add a
mechanism to propose and adopt aliases (committee of implementors + vote?).

Marc