[racket-dev] Generics updates

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 <stchang at 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 <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/cec1ac10/attachment-0001.html>