[racket-dev] Generics updates

No. Mutable sets would implement gen:set and then just have a few more
methods in the gen:mset interface. Structs can implement any number of
generics.

Jay

On Wed, Oct 2, 2013 at 1:31 PM, J. Ian Johnson <ianj at ccs.neu.edu> wrote:
> This means I can't interchange between mutable and immutable sets for my functions that only need to read generic sets, unless we further subdivide and have gen:set-query gen:set-constructor gen:set-mconstruct.
>
> -Ian
> ----- Original Message -----
> From: "Jay McCarthy" <jay.mccarthy at gmail.com>
> To: "Carl Eastlund" <cce at ccs.neu.edu>
> Cc: "Racket Developers" <dev at racket-lang.org>
> Sent: Wednesday, October 2, 2013 3:23:07 PM GMT -05:00 US/Canada Eastern
> Subject: Re: [racket-dev] Generics updates
>
> Regarding a point from RacketCon, I don't like that gen:set includes
> functions like set-add! and set-remove!. I think that sets with
> mutations are subclass of get:set and we should have a separate
> gen:mset (or something) interface for mutable versions.
>
> I dislike that an obvious implementation of sets, hash tables, are not
> sets to gen:set, because there are operations that cannot be performed
> on them.
>
> I think that "X implements generic G" should imply "All functions of G
> work on X". But this is not the case with gen:set and hasheq sets, for
> instance.
>
> Jay
>
>
> On Tue, Jul 23, 2013 at 9: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
>>
>
>
>
> --
> Jay McCarthy <jay at cs.byu.edu>
> Assistant Professor / Brigham Young University
> http://faculty.cs.byu.edu/~jay
>
> "The glory of God is Intelligence" - D&C 93
> _________________________
>   Racket Developers list:
>   http://lists.racket-lang.org/dev



-- 
Jay McCarthy <jay at cs.byu.edu>
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

"The glory of God is Intelligence" - D&C 93