The one real issue I see is the name make-set. I would much prefer make-hash-set (with *eq and *eqv versions), which indicates explicitly what kind of set it is, and leaves us open to future kinds of sets. Just like we don't call make-hash "make-dict", because there are many kinds of dicts, I don't think we should claim with our constructor that "make-set" is *the* constructor for sets.
Similarly for set-eq? and set-eqv?; we should have hash-set-eq? and hash-set-eqv?, because these predicates don't mean anything for "sets" in general. I would also propose adding hash-set? (like Sam said) and hash-set-equal?, because there's no reason to leave that one out. (Similarly for hash tables; if someone wants to guard hash tables with a contract on their equality predicate, there's no easy way to check for equal? based hash tables.) Carl Eastlund On Tue, Feb 23, 2010 at 9:16 AM, Matthew Flatt <[email protected]> wrote: > 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
