[racket-dev] [plt] Push #27395: master branch updated

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 <stamourv at 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 <asumu at 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