From: Phil Bewig <xxxxxx@swbell.net>
   Date: Wed, 12 Feb 2003 16:24:51 +0100
   References: <E18imE7-0005Q9-00@rosebud>

   Everyone who has seen a preliminary draft of this SRFI had the same
   comment that it should be split into "essential" and "library" pieces,
   but all had different ideas of where to make the split.

I don't care too much about where the split happens as long as the
core part isn't too big.  A dozen or so procedures and macros should
be enough to be useful while not being overwhelming.

   R5RS provides some guidance by including some functions on lists
   that it clearly labels "library procedures."

But note that the 'library' procedures are still included in the report.
It's a distinction based on implementation issues and has nothing to do
with clarity or utility.

   And [R5RS] omits such useful functions as FOLD and FILTER that are the
   basis of many other functions; you could even claim that FOLD should be
   included but LENGTH should be excluded, on the grounds that LENGTH
   is an easy one-liner given FOLD (I followed that logic when I moved
   LENGTH to the example section).

A list's length is one of its fundamental properties.  There are a zillion
different versions of FOLD.  I once wrote a macro to construct new versions
as needed.

   I guess my answer is pragmatic; include everything analogous to R5RS
   and the haskell prelude on the grounds that anything less leaves users
   of the library unsatisfied, then take the time to discuss all the pieces
   and produce something truly useful.

Just make sure that the situations are analogous.  For example, some of the
R5RS list procedures are typically used for S-expressions and are going to
be less useful for streams.  Similarly, whether a particular procedure did
or didn't make it into the Haskell prelude may have more to do with Haskell's
syntax or semantics than with the procedure's utility in Scheme.

   And what do you do about something like FILTER, which can be implemented
   without knowledge of the underlying representation but can use that knowledge
   to be much more efficient?

Splitting into two SRFIs doesn't mean that the implementation needs to
be split.  The implementation in the library SRFI can assume the use of
the implementation in the core SRFI.

Although I left it off of my list I think FILTER should go into the core
because of its combined utility and complexity.  People can't just generate
it when needed.

   And what would you do with CADADR?

I would drop it and all its friends.  The C[AD]+R's beyond CAR and CDR are
used more with general S-expressions than with proper lists.

                                               -Richard