> From: xxxxxx@freenetproject.org

    > On Thu, Oct 30, 2003 at 07:12:35AM -0800, bear wrote:

    > > So, yes, I'm advocating that the spec should require all collections
    > > that are going to work in this "generic collections framework" to
    > > adhere to a specific published data format -- probably as vectors
    > > or records encapsulating all the needed functions.

Hmm.

    > I feel that this will overly limit the usefulness in the long term.  In
    > the short term, yes, it may allow for drop in collections, but should a
    > real generic dispatch standard come about, it would not only invalidate
    > the mechanism you're describing, but the rest of SRFI-44 as well since
    > they would be specified in the same place.

    > It makes more sense to me to leave the implementation open, and possibly
    > follow up more or less immediately with an interface for adding
    > collections, with a reference implementation like the the system you
    > describe.  That way we get the best of both worlds... the ability to
    > drop in collections in the short term without the ticking time bomb of
    > eventual invalidation.

The reason to use separate srfis, it seems to me, would be to keep
apart elements that an implementation might reasonably want to provide
only part of -- to keep apart elements that are independently useful.

So, in that regard, I agree that a follow-up for collection
constructors (if not a full generics package), rather than adding
constructors to 44, makes some sense.

However, for the same reason, it _also_ makes sense to:

1) Trim 44 down to nothing more than (or less than, because I think
   it is useful) the procedures for sequences.

   Why sequences?  Because we have at least three examples of them
   (vectors, lists, and strings) which, while they all have different
   properties, all have in common that they're sequences -- so it
   makes perfect sense to write programs which are agnostic about what
   kind of sequence they operate on.

   In the reduced 44, you would also effectively be describing what
   the essential properties of a sequence are: future extensions that
   add new sequence types which these procedures might be extended to
   recognize have to preserve the required meaning of the generic
   sequence operations.

2) Drop bags for now because there is nothing that actually exists yet
   (in the universe of R5RS+srfis) which is a bag but not a sequence.

3) Drop sets for now because there is nothing that actually exists
   yet which is a set (or there's just one thing, a list, if you
   consider srfi-1).

4) Drop dictionaries for now because there's only one thing (44-style
   alists) which is actually a dictionary (or two, if you're also
   willing to consider ordinary alists in addition to "purely mutable"
   ones).

5) Then drop collections in general because all collections are
   sequences.

That makes 44 a lot like the sequence type in CL -- in other words,
there's really excellent precedent here.   It also admits a much
simpler reference implementation.

What I might do next, if I were you:

6) Write a variable-sized-hash-table srfi.

7) Write a dictionaries srfi with generics that operate on (ordinary)
   associative lists and hash tables (and possibly 44-style alists).

   Perhaps do the same thing by making a new set implementation, and
   then writing a sets srfi that encompases that and the LSET-*
   procedures from srfi-1

8) Let's all think about the possibility of a "generic functions"
   srfi.   No kidding that this is a large topic but I think it
   can be done.

Nothing would be lost by this approach.   Nothing in it _precludes_
ultimately arriving at, perhaps, the very spec you have now.  But the
advantages are:

a) separation of interfaces into independently useful chunks

b) no introduction of interfaces to types that don't exist
   or for which there is only one example

c) postponement of the generalized dispatching question until
   we have a clearer idea of what is really needed

d) definately doable by 28-Nov :-)

-t