[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A possible solution?

This page is part of the web mail archives of SRFI 44 from before July 7th, 2015. The new archives for SRFI 44 contain all messages, not just those from before July 7th, 2015.

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


Attachment: pgpJ6FupL27iY.pgp
Description: PGP signature