[racket-dev] Generics and data structures

At Wed, 9 May 2012 18:13:55 -0400,
Asumu Takikawa wrote:
> Ideally, we would provide similar interfaces for the other generic APIs
> in the tree, such as streams and sequences. However, the existing APIs
> rely on different representations for method tables from the one used by
> unstable/generics, specifically a vector of methods. This makes
> backwards compatibility complicated and we're not sure how to proceed.

We followed Ryan's recommendation, and now have a design (on Github)
that allows backwards compatibility with existing representations.

However, it turns out that the generic interfaces we mentioned present
additional complications that we didn't foresee.

For the gory details, read on.

>   * `prop:sequence`: Instead of a vector of methods, this struct
>     property takes a procedure which takes a struct instance and
>     produces a sequence (not a vector of methods).

Just like `prop:stream', it is used in the implementation of
`racket/base', so we can't redefine it to use the generics library.
(Our backwards compatibility story depends on the generics library being
the one defining the struct property.) We can think of two solutions:
 - Write the generics library in `#%kernel' and make it part of
   `racket/base'. (Which would be premature, given how new the generics
   library is.)
 - Move `for' from `racket/base' to `racket/for' so that streams and
   sequences can depend on the generics library.
Neither of these sound desirable. Can anyone think of other solutions?

>   * `prop:equal+hash-code` uses a list of methods instead of a vector.

That one is defined in the C code, so we can't redefine it. However, if
the property's guard and its clients (`equal?', `hash') are changed to
accept both lists of methods (as they currently do) and vectors of
methods (as the generics library would produce), we could make it work.
Would this be a reasonable solution?

>   * `prop:dict/contract` is given both a method vector and a vector
>     of sub-contracts that are used to assemble the method contracts.
>     The generics library currently uses a single vector.

We have a general design for contracting generic interfaces, which would
cover this case. We're working on implementing it.

Thanks for your feedback!

Vincent