[racket-dev] Generics updates

> 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 <stchang at 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 <stchang at 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 <cce at 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 <cce at 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
>> >> >
>> >>
>> >
>>
>