On Fri, 26 Mar 1999, Marc Feeley wrote:

> > So, in conclusion, I don't think leanness and simplicity is
> > sacrificed by making SRFI 0 more elaborate.  I think making SRFI 0
> > more elaborate is necessary to make it sufficiently useful.
>
> At this point I think we really need more input from others and
> particularly implementors.  As I have said before SRFI-0 is at the
> heart of the SRFI process so we need to have something that has
> widespread acceptance.

I completely agree that SRFI-0 is the kernel of SRFI's success.  From an
implementor's point of view, I assume all of the participants here will
implement whatever is adopted.  However, I want to emphasize that
widespread acceptance goes beyond implementation and into _use_.  If
implementors and programmers feel that SRFI-0 is too weak, they will
augment it and deprecate its usage in all but the most portability-
sensitive applications.  And if that happens, SRFI-0 will have missed its
opportunity, to the detriment of the process (but not fatal).

For myself, in its original form, I would rarely use SRFI-0 because of its
everything's-there premise.  This is expensive (imagine 1000 SRFIs that
have to be loaded) and weak (conflicting SRFIs).

>   My views can be bent if I see that enough
> people want a particular form (multiway conditional, support for
> "and", "or", "not", etc).
>
> So I send a plea to everyone: if you have a view on this subject now
> is the time to voice it.

As we've discussed before, I think the original SRFI-0 is too limited to
be widely useful. In our previous discussion, I was convinced that the
problems I saw would be handled by external means (such as command-line
options).  I can live with that, but don't like it.

I definitely think a richer mechanism would be nicer.  The problem of
nesting if-implements to achieve ad-hoc complex tests is a real one, and
the `cond' style and the conjunct/disjunct both address this well.

My impression of the point of SRFIs is to standardize implementations of
useful features.  If users have to write macros to implement 'or' and
'and' on top of if-implements, then we've sort of missed the target.  If
those macros are in another SRFI, then everybody will be compelled to use
if-implements to include their own re-implementation of those macros in
case that SRFI is not implemented.

As a programmer, I want the richest possible set of features to be
available without having to think about it.

For RScheme at least, it does not appear to be noticably more difficult to
implement the modified SRFI-0 (although I haven't implemented the
READER-SYNTAX part yet).  As for other implementations, SRFI-0 does not
require a dynamically loadable module system, so I don't see it being
infeasible for other systems.  The text gives a compelling argument for a
minimalist implementation.

In any case, a lot of this thinking is mostly speculation -- I haven't
used any similar systems.  CPP is not internally extensible, m4 operates
in a totally different realm, and Lisp #+/#- operates much earlier
(although its probably the closest in flavor).  It's difficult to predict
the consequences of design choices at this point.

I don't have a good handle on what SRFIs are going to look like (though
there are a few, now) and how programs are going to want to use SRFI-0 to
introspect on their environment.  (My best working example of using SRFI-0
is in RScheme's cross-compiler.  The same source code needs to run both in
various preceding versions of RScheme as well as in its own version; using
either form of SRFI-0 to manage those differences has been very nice so
far.)

In summary, I would encourage the incorporation of the modifications to
SRFI-0.

-- Donovan Kolbly                    (  xxxxxx@rscheme.org
				     (  http://www.rscheme.org/~donovan/

P.S.  I'd love to finish my implementation before the discussion is over,
though.  I often find little gotchas in the course of actual
implementation!  I don't know how other implementors work, but I would
encourage others to do the same if they haven't already.