<div dir="ltr">No, that doesn't work. If someone implements, say, an efficient subset? test, then set=? should use that rather than iterating using set->stream and set-member?. You should use the highest-level methods you can, in order to get the most out of an implementation. Which is why I made all the fallback implementations I did, to give implementers the best flexibility possible for getting a good implementation of all methods for the minimum possible effort on their part. Similarly, I don't want to make set->stream primitive, because if someone does implement set-first and set-rest, it should be derivable. </div><div class="gmail_extra"> <div>Carl Eastlund</div> <div class="gmail_quote">On Thu, Aug 1, 2013 at 7:26 PM, Stephen Chang <<a href="mailto:stchang@ccs.neu.edu" target="_blank">stchang@ccs.neu.edu</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class="im">> Would it be better to just remove the "primitve" / "derived" distinction, > since it's somewhat artificial, and leave it up to the individual method > descriptions? Is there some better way I should be describing things? </div>Ok I can see now that there's no easy way to organize the methods. I think we should keep some distinction, since as a programmer it's good to know exactly what methods I have to implement. However, to me "fallback" implies that I should get it for free, so it seems most intuitive if derived methods only depend on primitive methods. Then for some subset of primitive methods that I implement, I should get the derived methods that depend on those primitives. I'll have to think more about what should be derived and primitive, but for now I think the easiest thing is to edit the docs to move set->stream (or some equivalent) into the primitive list? <div class="HOEnZb"><div class="h5"> > > Carl Eastlund > > > On Thu, Aug 1, 2013 at 6:51 PM, Stephen Chang <<a href="mailto:stchang@ccs.neu.edu">stchang@ccs.neu.edu</a>> wrote: >> >> > For the other part, I either should have made it as you say -- implement >> > the > "primitive" ones and you get the others -- or else I should have >> > clearly >> > documented the relationship somewhere. >> >> You did document the dependencies, but some of them are circular, ie >> some derived rely on other derived. I'd definitely be happy to patch >> things myself, but I guess I dont have a concrete complaint yet :), >> only that the distinctions feel somewhat arbitrary and did not match >> my initial intuition, which is why I'm looking for additional insight. >> >> >> > Do you have examples of which ones don't come "for free" with the >> > primitive >> > methods? >> >> Very few of the derived come free because most rely on set->stream, >> but set->stream is not "primitive" which is why I thought there might >> be a distinction between iterable sets and non-iterable. >> >> >> >> >> > >> > Carl Eastlund >> > >> > >> > On Thu, Aug 1, 2013 at 6:27 PM, Stephen Chang <<a href="mailto:stchang@ccs.neu.edu">stchang@ccs.neu.edu</a>> >> > wrote: >> >> >> >> Just played a bit with gen:set. It looks great and in particular the >> >> fallback implementations are very convenient. >> >> >> >> One comment: the distinction between "primitive" methods and "derived" >> >> methods confused me somewhat. Can you explain the reasoning for >> >> determining which is which? >> >> >> >> For example, when I first read the docs, I thought that if I >> >> implemented the primitives, I would get the derived, but that's not >> >> the case since some of the derived methods depend on each other. >> >> Reading the docs more thoroughly, it sort of seems like there's an >> >> implicit separation along the lines of iterability, ie, derived sets >> >> are "iterable" since many of the derived methods require set->stream, >> >> but that's not exactly right either. >> >> >> >> >> >> On Thu, Jul 25, 2013 at 1:58 PM, Carl Eastlund <<a href="mailto:cce@ccs.neu.edu">cce@ccs.neu.edu</a>> wrote: >> >> > After some fixes, mostly to contracts and documentation, I've pushed >> >> > the >> >> > new >> >> > generics and set features to the master branch. >> >> > >> >> > Carl Eastlund >> >> > >> >> > >> >> > On Tue, Jul 23, 2013 at 11: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> >> >> > >> >> >> > >> > </div></div></blockquote></div> </div>