<div dir="ltr">If we do go this way, we should be careful about the subtyping relationship since we want a predicate that means "will not be mutated and I can rely on that to reason about my library's behavior" and if mutable sets are a sub-thing of immutable ones, we might lose that (depending on how things are set up).<div> </div><div>Robby</div></div><div class="gmail_extra"> <div class="gmail_quote">On Wed, Oct 2, 2013 at 2:57 PM, Jay McCarthy <<a href="mailto:jay.mccarthy@gmail.com" target="_blank">jay.mccarthy@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">No. Mutable sets would implement gen:set and then just have a few more methods in the gen:mset interface. Structs can implement any number of generics. Jay <div class="HOEnZb"><div class="h5"> On Wed, Oct 2, 2013 at 1:31 PM, J. Ian Johnson <<a href="mailto:ianj@ccs.neu.edu">ianj@ccs.neu.edu</a>> wrote: > This means I can't interchange between mutable and immutable sets for my functions that only need to read generic sets, unless we further subdivide and have gen:set-query gen:set-constructor gen:set-mconstruct. > > -Ian > ----- Original Message ----- > From: "Jay McCarthy" <<a href="mailto:jay.mccarthy@gmail.com">jay.mccarthy@gmail.com</a>> > To: "Carl Eastlund" <<a href="mailto:cce@ccs.neu.edu">cce@ccs.neu.edu</a>> > Cc: "Racket Developers" <<a href="mailto:dev@racket-lang.org">dev@racket-lang.org</a>> > Sent: Wednesday, October 2, 2013 3:23:07 PM GMT -05:00 US/Canada Eastern > Subject: Re: [racket-dev] Generics updates > > Regarding a point from RacketCon, I don't like that gen:set includes > functions like set-add! and set-remove!. I think that sets with > mutations are subclass of get:set and we should have a separate > gen:mset (or something) interface for mutable versions. > > I dislike that an obvious implementation of sets, hash tables, are not > sets to gen:set, because there are operations that cannot be performed > on them. > > I think that "X implements generic G" should imply "All functions of G > work on X". But this is not the case with gen:set and hasheq sets, for > instance. > > Jay > > > On Tue, Jul 23, 2013 at 9:37 AM, Carl Eastlund <<a href="mailto:cce@ccs.neu.edu">cce@ccs.neu.edu</a>> wrote: >> My work on adding gen:set, and related changes to define-generics and >> gen:dict, is ready for review and (hopefully) to push to the master branch. >> The branch moved in the process of cleaning things up, it's now at: >> >> <a href="https://github.com/carl-eastlund/racket/tree/generics-from-scratch" target="_blank">https://github.com/carl-eastlund/racket/tree/generics-from-scratch</a> >> >> (The "from scratch" just refers to the process of rebuilding the git >> history, I didn't go out of my way to rewrite anything in the code base from >> scratch, although in some places a lot of code did move around.) >> >> What's new in the branch: >> >> - Generics now support a few new options >> - #:fallbacks specifies fallback method implementations for instances with >> no implementation >> - #:fast-defaults specifies instances on a "fast path", useful for >> built-in types >> - #:defined-predicate gives a more intuitive and efficient interface than >> #:defined-table >> - #:derive-property allows generics to piggy-back on existing struct >> properties >> >> - Sets are now a generic datatype through gen:set >> - lists are now sets >> - the built-in set types are now documented as "hash sets" >> - there are mutable and weak hash sets >> - you can define new set types quickly with define-custom-set-types >> - most set operations are now methods with fallbacks >> - sets now support -copy and -clear operations, plus mutating [!] versions >> of operations >> >> - Dictionaries have a few changes >> - new macro define-custom-hash-types [*] >> - most dict operations are now methods with fallbacks >> - dicts now support -copy, -clear, -clear!, and -empty? operations >> >> I've run some benchmarks and performance of the various generic operations >> are comparable to the current HEAD, so there should be no major performance >> changes with this patch. >> >> [*] I've added define-custom-hash-types and define-custom-set-types rather >> than just adding make-custom-set akin to make-custom-hash because >> make-custom-hash is hard to use. The documented behavior -- that any custom >> hash is equal to any other created with the same bindings and predicates / >> hash functions -- was never true and can be expensive or at least tricky to >> implement. It seemed more sensible to just remove the erroneous >> documentation on make-custom-hash, and add the definition form to create >> constructors for new, explicitly-compatible dict and set types. Both >> definition forms bind predicates and constructors for new (set or dict) >> types with immutable, mutable, and weak variants that inter-operate. >> >> If there are no serious issues brought up in the next day or two, I'll push >> it to the development branch, since our current release process isn't >> following HEAD. >> >> Carl Eastlund >> >> _________________________ >> Racket Developers list: >> <a href="http://lists.racket-lang.org/dev" target="_blank">http://lists.racket-lang.org/dev</a> >> > > > > -- > Jay McCarthy <<a href="mailto:jay@cs.byu.edu">jay@cs.byu.edu</a>> > Assistant Professor / Brigham Young University > <a href="http://faculty.cs.byu.edu/~jay" target="_blank">http://faculty.cs.byu.edu/~jay</a> > > "The glory of God is Intelligence" - D&C 93 > _________________________ > Racket Developers list: > <a href="http://lists.racket-lang.org/dev" target="_blank">http://lists.racket-lang.org/dev</a> -- Jay McCarthy <<a href="mailto:jay@cs.byu.edu">jay@cs.byu.edu</a>> Assistant Professor / Brigham Young University <a href="http://faculty.cs.byu.edu/~jay" target="_blank">http://faculty.cs.byu.edu/~jay</a> "The glory of God is Intelligence" - D&C 93 _________________________ Racket Developers list: <a href="http://lists.racket-lang.org/dev" target="_blank">http://lists.racket-lang.org/dev</a> </div></div></blockquote></div> </div>