> 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