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. Carl Eastlund On Thu, Aug 1, 2013 at 7:26 PM, Stephen Chang <stch...@ccs.neu.edu> wrote: > > 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? > > 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? > > > > > > > Carl Eastlund > > > > > > On Thu, Aug 1, 2013 at 6:51 PM, Stephen Chang <stch...@ccs.neu.edu> > 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 <stch...@ccs.neu.edu> > >> > 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 <c...@ccs.neu.edu> > 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 <c...@ccs.neu.edu> > >> >> > 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: > >> >> >> > >> >> >> > https://github.com/carl-eastlund/racket/tree/generics-from-scratch > >> >> >> > >> >> >> (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: > >> >> > http://lists.racket-lang.org/dev > >> >> > > >> >> > >> > > >> > > > >
_________________________ Racket Developers list: http://lists.racket-lang.org/dev