I don't see how it's a problem to add new constructors in the future and to liberalize the contracts on the `set' functions for those future variants. I'll readily concede, however, to anyone who wants to do the work of improving the current first cut.
At Tue, 23 Feb 2010 08:53:18 -0500, Sam Tobin-Hochstadt wrote: > On Tue, Feb 23, 2010 at 8:35 AM, Matthew Flatt <[email protected]> wrote: > > At Mon, 22 Feb 2010 20:39:54 -0500, Carl Eastlund wrote: > >> I appreciate the addition of sets to PLT datatypes, but the > >> implementation just added to the trunk is very specific to immutable, > >> hash table-based sets. In the spirit of scheme/dict, which allows for > >> a variety of more interesting dictionary representations, can we leave > >> scheme/set open to other representations of sets? > > > > Does something in the current `scheme/set' API preclude future > > extensibility (e.g., adding `prop:set')? > > The following aspects of `scheme/set' seem designed-in to the current API: > > - that elements must not be mutated (even if there were other > implementations, the fact that the primary one has this restriction > means that it's not safe) > - the three comparison functions are written in to the API, rather > than being extensible (which would be hard to change given the current > implementation, since those are the hash functions that are allowed) > > One nice way to improve this would be to have a concept of 'hash > sets', where (hash-set? s) implies (set? s). That leaves open the > door to equality based or comparison based sets in the future. Almost > all of the API would stay the same, but the constructors and > predicates would change. > -- > sam th > [email protected] _________________________________________________ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev
