[racket-dev] Generics updates

Ah, yes, set->stream isn't primitive because it can be derived if you have
set-first and either set-rest or set-remove.  And I know there are
dependency cycles, this is intentional so that you can implement any one of
several related things, but most of them were supposed to go all the way
down to primitive methods (in some sense) if all else failed.

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?

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
> >> >
> >>
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/dev/archive/attachments/20130801/eb7773ef/attachment.html>