As it stands the Set type constructor is for hash sets. Changing that would break backwards compatibility and pr13989 is for the issue of changing the meaning/any change.
I think there is a bunch of existing code that assumes that Set is exactly hashsets, or at least covariant. On Fri, Aug 30, 2013 at 5:37 PM, Vincent St-Amour <stamo...@ccs.neu.edu> wrote: > I was thinking of the `Set' type constructor as meaning generic set, > which is why I gave that type to `generic-set?'. This interpretation is > a problem because TR treats sets as covariant. > > If we make sets invariant, could TR support generic sets? [1] Or are > there other issues I'm missing? > > Vincent > > > [1] Better support would also include subtyping between lists and sets. > > > At Fri, 30 Aug 2013 16:38:11 -0700, > Eric Dobson wrote: >> >> Isn't the assymetric check the wrong way? If it returns true, we know >> nothing because it might not be a hash-set, but if it returns false >> then we know that it is not a hash set? >> >> On Fri, Aug 30, 2013 at 3:30 PM, Asumu Takikawa <as...@ccs.neu.edu> wrote: >> > On 2013-08-30 16:15:23 -0400, Sam Tobin-Hochstadt wrote: >> >> I worry about mutable sets here, but I can't think of any bugs it can >> >> cause ATM. >> > >> > I don't have any segfault-causing bugs, but here's a violation of the blame >> > theorem: >> > >> > #lang racket >> > >> > (module a0 racket >> > (define s (mutable-set 1 2 3)) >> > (provide s)) >> > >> > (module a typed/racket >> > (require/typed (submod ".." a0) [s Any]) >> > (: x (Setof Any)) >> > (define x (assert s generic-set?)) >> > (provide x)) >> > >> > (require 'a) >> > x >> > >> > Cheers, >> > Asumu >> > _________________________ >> > Racket Developers list: >> > http://lists.racket-lang.org/dev _________________________ Racket Developers list: http://lists.racket-lang.org/dev