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
