Thanks for adding the set library. I am looking forward to using these
in *SL.
On Feb 23, 2010, at 9:16 AM, Matthew Flatt 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
_________________________________________________
For list-related administrative tasks:
http://list.cs.brown.edu/mailman/listinfo/plt-dev
