Re: A possible solution?

[scgmille@xxxxxxxxxxxxxxxxxx]

> 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.

What would concrete implementations of bags, sets, and dictionaries look 
to for reference?  

> 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.

I'm quite likely to write a priority queue bag shortly after SRFI-44.

> 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).

Same as 2).

> 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.
> 
So basically you want to drop all these useful types because they don't 
exist yet?  That makes so much sense.  

> 
> What I might do next, if I were you:
> 
> 6) Write a variable-sized-hash-table srfi.  

It won't be me, but it will certainly happen.  That will probably be the 
first concrete collection we see.

> 
> 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.    

I agree.
> 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

But interoperability is exactly the point of the SRFI.  I really wish 
people would stop proposing the "write everything later and then try and 
make them work together" strategy.

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

There is only harm in this if they're wrong.

> c) postponement of the generalized dispatching question until
>    we have a clearer idea of what is really needed
We're postponing it quite well at the moment, by not specifying it.

	Scott

Attachment: pgpJ6FupL27iY.pgp
Description: PGP signature