Re: [racket-dev] Generics and data structures

2012-05-10 Thread Vincent St-Amour
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,

Re: [racket-dev] Generics and data structures

2012-05-09 Thread Asumu Takikawa
On 2012-05-09 18:02:04 -0600, Ryan Culpepper wrote: > See the 'supers' argument to 'make-struct-type-property'. > > Create 'real-prop:sequence' that takes a vector (compatible with > generics library). > > Define 'prop:sequence' as a backwards compatibility property that > takes an old-style implem

Re: [racket-dev] Generics and data structures

2012-05-09 Thread Asumu Takikawa
On 2012-05-09 19:01:10 -0400, Neil Van Dyke wrote: > When you say "dictionaries, sequences,", are you including the > Racket types hash, vector, and list? Yes, the changes we made to racket/dict will work with hashes, vectors, and a-lists in the same way it did before. The only difference is when

Re: [racket-dev] Generics and data structures

2012-05-09 Thread Ryan Culpepper
On 05/09/2012 04:13 PM, Asumu Takikawa wrote: Hi all, Racket currently provides several generic extensible data structure APIs such as dictionaries, sequences, streams, and so on. Unfortunately, each data structure currently has its own extension API, but no consistent convention exists: some AP

Re: [racket-dev] Generics and data structures

2012-05-09 Thread Neil Van Dyke
Asumu Takikawa wrote at 05/09/2012 06:13 PM: Any thoughts or suggestions? When you say "dictionaries, sequences,", are you including the Racket types hash, vector, and list? If so, would current performance for those Racket types be affected? And does this have implications for what op

[racket-dev] Generics and data structures

2012-05-09 Thread Asumu Takikawa
Hi all, Racket currently provides several generic extensible data structure APIs such as dictionaries, sequences, streams, and so on. Unfortunately, each data structure currently has its own extension API, but no consistent convention exists: some APIs use lists of methods, some use vectors, etc.