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.
> From: scgmille@xxxxxxxxxxxxxxxxxx > 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