[plt-dev] scheme/set

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 <mflatt at cs.utah.edu> 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
> samth at ccs.neu.edu