<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br></div><div>This whole discussion reminds me of the idea of specialization interface specification. The notion is due to Lamping, I think. Stevie and I read the paper and his class contracts provide some of the power of SIs but not all. In particular, they fail to provide the power that seems to be necessary here: </div><div><br></div><div> specifying the cycles among methods that is required to be overridden wholesale </div><div> &&</div><div> specifying the 'what I get for free' methods </div><div><br></div><div>As far as I know, there is no PL that actually supports such specs and everyone relies on plain old English docs to get this across. Then everyone gets it wrong the first time and plays until it works. </div><div><br></div><div>It's quite likely to be a DLS-level research paper, possibly OOPSLA if we integrate it with a type system eventually. -- Matthias</div><div><br></div><div><br></div><div><br></div><div><br></div><br><div><div>On Aug 1, 2013, at 7:30 PM, Carl Eastlund wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><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.<br>
<br>Similarly, I don't want to make set->stream primitive, because if someone does implement set-first and set-rest, it should be derivable.<br></div><div class="gmail_extra"><br clear="all"><div>Carl Eastlund</div>
<br><br><div class="gmail_quote">On Thu, Aug 1, 2013 at 7:26 PM, Stephen Chang <span dir="ltr"><<a href="mailto:stchang@ccs.neu.edu" target="_blank">stchang@ccs.neu.edu</a>></span> wrote:<br><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,<br>
> since it's somewhat artificial, and leave it up to the individual method<br>
> descriptions? Is there some better way I should be describing things?<br>
<br>
</div>Ok I can see now that there's no easy way to organize the methods.<br>
<br>
I think we should keep some distinction, since as a programmer it's<br>
good to know exactly what methods I have to implement. However, to me<br>
"fallback" implies that I should get it for free, so it seems most<br>
intuitive if derived methods only depend on primitive methods. Then<br>
for some subset of primitive methods that I implement, I should get<br>
the derived methods that depend on those primitives. I'll have to<br>
think more about what should be derived and primitive, but for now I<br>
think the easiest thing is to edit the docs to move set->stream (or<br>
some equivalent) into the primitive list?<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
><br>
> Carl Eastlund<br>
><br>
><br>
> On Thu, Aug 1, 2013 at 6:51 PM, Stephen Chang <<a href="mailto:stchang@ccs.neu.edu">stchang@ccs.neu.edu</a>> wrote:<br>
>><br>
>> > For the other part, I either should have made it as you say -- implement<br>
>> > the > "primitive" ones and you get the others -- or else I should have<br>
>> > clearly<br>
>> > documented the relationship somewhere.<br>
>><br>
>> You did document the dependencies, but some of them are circular, ie<br>
>> some derived rely on other derived. I'd definitely be happy to patch<br>
>> things myself, but I guess I dont have a concrete complaint yet :),<br>
>> only that the distinctions feel somewhat arbitrary and did not match<br>
>> my initial intuition, which is why I'm looking for additional insight.<br>
>><br>
>><br>
>> > Do you have examples of which ones don't come "for free" with the<br>
>> > primitive<br>
>> > methods?<br>
>><br>
>> Very few of the derived come free because most rely on set->stream,<br>
>> but set->stream is not "primitive" which is why I thought there might<br>
>> be a distinction between iterable sets and non-iterable.<br>
>><br>
>><br>
>><br>
>><br>
>> ><br>
>> > Carl Eastlund<br>
>> ><br>
>> ><br>
>> > On Thu, Aug 1, 2013 at 6:27 PM, Stephen Chang <<a href="mailto:stchang@ccs.neu.edu">stchang@ccs.neu.edu</a>><br>
>> > wrote:<br>
>> >><br>
>> >> Just played a bit with gen:set. It looks great and in particular the<br>
>> >> fallback implementations are very convenient.<br>
>> >><br>
>> >> One comment: the distinction between "primitive" methods and "derived"<br>
>> >> methods confused me somewhat. Can you explain the reasoning for<br>
>> >> determining which is which?<br>
>> >><br>
>> >> For example, when I first read the docs, I thought that if I<br>
>> >> implemented the primitives, I would get the derived, but that's not<br>
>> >> the case since some of the derived methods depend on each other.<br>
>> >> Reading the docs more thoroughly, it sort of seems like there's an<br>
>> >> implicit separation along the lines of iterability, ie, derived sets<br>
>> >> are "iterable" since many of the derived methods require set->stream,<br>
>> >> but that's not exactly right either.<br>
>> >><br>
>> >><br>
>> >> On Thu, Jul 25, 2013 at 1:58 PM, Carl Eastlund <<a href="mailto:cce@ccs.neu.edu">cce@ccs.neu.edu</a>> wrote:<br>
>> >> > After some fixes, mostly to contracts and documentation, I've pushed<br>
>> >> > the<br>
>> >> > new<br>
>> >> > generics and set features to the master branch.<br>
>> >> ><br>
>> >> > Carl Eastlund<br>
>> >> ><br>
>> >> ><br>
>> >> > On Tue, Jul 23, 2013 at 11:37 AM, Carl Eastlund <<a href="mailto:cce@ccs.neu.edu">cce@ccs.neu.edu</a>><br>
>> >> > wrote:<br>
>> >> >><br>
>> >> >> My work on adding gen:set, and related changes to define-generics<br>
>> >> >> and<br>
>> >> >> gen:dict, is ready for review and (hopefully) to push to the master<br>
>> >> >> branch.<br>
>> >> >> The branch moved in the process of cleaning things up, it's now at:<br>
>> >> >><br>
>> >> >> <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><br>
>> >> >><br>
>> >> >> (The "from scratch" just refers to the process of rebuilding the git<br>
>> >> >> history, I didn't go out of my way to rewrite anything in the code<br>
>> >> >> base<br>
>> >> >> from<br>
>> >> >> scratch, although in some places a lot of code did move around.)<br>
>> >> >><br>
>> >> >> What's new in the branch:<br>
>> >> >><br>
>> >> >> - Generics now support a few new options<br>
>> >> >> - #:fallbacks specifies fallback method implementations for<br>
>> >> >> instances<br>
>> >> >> with no implementation<br>
>> >> >> - #:fast-defaults specifies instances on a "fast path", useful for<br>
>> >> >> built-in types<br>
>> >> >> - #:defined-predicate gives a more intuitive and efficient<br>
>> >> >> interface<br>
>> >> >> than #:defined-table<br>
>> >> >> - #:derive-property allows generics to piggy-back on existing<br>
>> >> >> struct<br>
>> >> >> properties<br>
>> >> >><br>
>> >> >> - Sets are now a generic datatype through gen:set<br>
>> >> >> - lists are now sets<br>
>> >> >> - the built-in set types are now documented as "hash sets"<br>
>> >> >> - there are mutable and weak hash sets<br>
>> >> >> - you can define new set types quickly with<br>
>> >> >> define-custom-set-types<br>
>> >> >> - most set operations are now methods with fallbacks<br>
>> >> >> - sets now support -copy and -clear operations, plus mutating [!]<br>
>> >> >> versions of operations<br>
>> >> >><br>
>> >> >> - Dictionaries have a few changes<br>
>> >> >> - new macro define-custom-hash-types [*]<br>
>> >> >> - most dict operations are now methods with fallbacks<br>
>> >> >> - dicts now support -copy, -clear, -clear!, and -empty? operations<br>
>> >> >><br>
>> >> >> I've run some benchmarks and performance of the various generic<br>
>> >> >> operations<br>
>> >> >> are comparable to the current HEAD, so there should be no major<br>
>> >> >> performance<br>
>> >> >> changes with this patch.<br>
>> >> >><br>
>> >> >> [*] I've added define-custom-hash-types and define-custom-set-types<br>
>> >> >> rather<br>
>> >> >> than just adding make-custom-set akin to make-custom-hash because<br>
>> >> >> make-custom-hash is hard to use. The documented behavior -- that<br>
>> >> >> any<br>
>> >> >> custom<br>
>> >> >> hash is equal to any other created with the same bindings and<br>
>> >> >> predicates /<br>
>> >> >> hash functions -- was never true and can be expensive or at least<br>
>> >> >> tricky to<br>
>> >> >> implement. It seemed more sensible to just remove the erroneous<br>
>> >> >> documentation on make-custom-hash, and add the definition form to<br>
>> >> >> create<br>
>> >> >> constructors for new, explicitly-compatible dict and set types.<br>
>> >> >> Both<br>
>> >> >> definition forms bind predicates and constructors for new (set or<br>
>> >> >> dict)<br>
>> >> >> types with immutable, mutable, and weak variants that inter-operate.<br>
>> >> >><br>
>> >> >> If there are no serious issues brought up in the next day or two,<br>
>> >> >> I'll<br>
>> >> >> push it to the development branch, since our current release process<br>
>> >> >> isn't<br>
>> >> >> following HEAD.<br>
>> >> >><br>
>> >> >> Carl Eastlund<br>
>> >> ><br>
>> >> ><br>
>> >> ><br>
>> >> > _________________________<br>
>> >> > Racket Developers list:<br>
>> >> > <a href="http://lists.racket-lang.org/dev" target="_blank">http://lists.racket-lang.org/dev</a><br>
>> >> ><br>
>> >><br>
>> ><br>
>><br>
><br>
<br>
</div></div></blockquote></div><br></div>
_________________________<br> Racket Developers list:<br> <a href="http://lists.racket-lang.org/dev">http://lists.racket-lang.org/dev</a><br></blockquote></div><br></body></html>