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. Scott
Description: PGP signature