Short(ish) answer until I get reliable internet in my new apartment -- gen:set is modeled after gen:dict. I don't want us to have a new design for each interface. Because methods are optional, we get by with one name for one or more related subinterfaces. That's the principle by which I justified set-add and set-add! In one interface. And if we separate them, we need one interface with just queries, then four more for add, remove, add!, and remove!, at the very least. It's a messy direction to go in. Carl Eastlund -- WARNING! Poorly-typed cell phone email precedes. <div class="gmail_quote">On Oct 2, 2013 4:35 PM, "Jay McCarthy" <<a href="mailto:jay.mccarthy@gmail.com">jay.mccarthy@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> I agree. I think the important thing with generics is unlike mpair? the set? predicate only necessarily implies that the methods are available (which is the source of my original complaint). We need to design the meaning of predicates just like we design the interface. I think that if we want mset to be a set then set? cannot imply immutable? but since that is a valuable property, it is worth designing a predicate that gives it, if only as a human thing. Jay On Wed, Oct 2, 2013 at 2:29 PM, Robby Findler <<a href="mailto:robby@eecs.northwestern.edu">robby@eecs.northwestern.edu</a>> wrote: > That sounds right. > > But just in case there is any confusion on the larger point: predicates as > way we check properties to ensure good properties of our abstractions is one > of the important things that we have mostly gotten right in Racket. > Chaperones, separate pair? and mpair? predicates, and presumably lots of > other stuff are the way they are for this kind of reason. > > Robby > > > On Wed, Oct 2, 2013 at 3:21 PM, Jay McCarthy <<a href="mailto:jay.mccarthy@gmail.com">jay.mccarthy@gmail.com</a>> wrote: >> >> Even if we were to remove set-add! from gen:set and not great gen:mset >> then that would not be a vaild property. Generics are a lower bound on >> the interface, not an upper bound, so there could be other functions >> on the data structure that implement mutation. For instance, a gen:set >> could be made for an external resource that was set-like. >> >> I think what you want is something like gen:fset that has no methods, >> but is used for set authors to tag their set as having this property >> for the benefit of consumers (which cannot be enforced.) Your library >> would then consume fsets and not sets. >> >> Jay >> >> >> On Wed, Oct 2, 2013 at 2:09 PM, Robby Findler >> <<a href="mailto:robby@eecs.northwestern.edu">robby@eecs.northwestern.edu</a>> wrote: >> > 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). >> > >> > Robby >> > >> > >> > On Wed, Oct 2, 2013 at 2:57 PM, Jay McCarthy <<a href="mailto:jay.mccarthy@gmail.com">jay.mccarthy@gmail.com</a>> >> > wrote: >> >> >> >> 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 >> >> >> >> 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> >> > >> > >> >> >> >> -- >> 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 > > -- 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> </blockquote></div>