[plt-dev] scheme/set

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