Re: Scheme RFCs

[Alan Bawden <Alan@lcs.mit.edu>]

   Date: Mon, 16 Nov 1998 14:18:11 -0600 (CST)
   From: Matthias Felleisen <matthias@cs.rice.edu>
   ...
   2. BUT, recall that we also wanted to give Scheme implementors the ability
      to provide a mechanism like 

	 (require-srfi 'srfi123 'srfi45 'srfi3)

      with which a programmer can request the reference implementations of
      SRFI, if provided. 

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.

   3. So, I suggest that we distinguish between SRFIs that are requesting an
      implementation and those that record a factoid ( (! 1) = 1 :-). How the
      SRFI people do that, I don't care. They can use names like iSRFI and
      fSRFI or have two separate threads ... 

      Personally I think that two separate "threads" would be best: one that
      would be `restrictive' as suggested by the SRFI editors and another that
      would be `open' as suggested by Alan, Olin, etc. 

I don't see the need for the restrictive RFCs at all.  What danger is this
filtering mechanism defending us against?