<div dir="ltr">That sounds right. <div> </div><div>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.<div> </div><div>Robby</div></div></div><div class="gmail_extra"> <div class="gmail_quote">On Wed, Oct 2, 2013 at 3:21 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">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 <div class="HOEnZb"><div class="h5"> 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 </div></div></blockquote></div> </div>