At Sat, 4 Oct 2014 10:13:14 -0500, Robby Findler wrote: > That said, I do think that our integration of generic operations and > our standard library deserves some more care and perhaps redesign to > make things hang together better. As it stands, we have some > conveniences, but they are limited by backwards compatibility concerns > (like the one in the previous paragraph). I have heard that some are > considering this as part of "racket2" but I don't know how far along > those plans are.
Last year, I started work on a generics-based collections library: https://github.com/stamourv/generic-collections I agree that something like this should be part of Racket 2, and I think that this library may be a good starting point. The closest I have to documentation is the description of the interfaces involved: https://github.com/stamourv/generic-collections/blob/master/main.rkt#L748 I started writing a design document, to better explain the big picture, but I haven't finished it. If there is interest in exploring that space, I can spend some time to polish it. If anyone has comments, suggestions, or would like to help, don't hesitate! I don't currently have time to work on this (but hope to in the future!), but would be happy to help anyone who decides to. Here's a brief summary of some of the highlights: - The library is designed to accomodate generic consumption, construction and transformation of collections, while preserving the "type" of a collection (e.g. mapping from lists to lists and vectors to vectors, not from lists to an opaque sequence type, as the current sequence functions do). - The library accomodates both "structural" collections (such as lists), that are built and traversed structurally, and "indexed" collections (such as vectors) that are built and traversed statefully. - Thanks to generics' fallback methods, it's possible for collection implementers to define a few basic methods, and get a lot of methods (think all of racket/list) for free, while still being able to override specific operations. A collection that implements either the "structural traversal" set of methods (`empty?`, `first` and `rest`) or the "stateful traversal" set of methods (`make-iterator`, which returns something that implements the `gen:iterator` interface) gets `foldr`, `length`, etc. for free. A collection that implemements either the "structural building" set of methods (`cons` and `make-empty` (generics need an instance to dispatch on, so we can't just have a generic `empty`)) or the "stateful building" set of methods (`make-builder`, which returns something that implements the `gen:builder` interface) gets `range`, `make` (think `make-list`) and `build` (think `build-list`) for free. A collection that implements traversal and building methods gets all "transducer"[1] methods (`map`, `filter`, etc.) for free. - Thanks to generics' default methods, it's possible to retrofit these interfaces on top of built-in datatypes. This should make that library a 95% compatible[2] replacement for the current collection operations. - Operations are n-ary where it makes sense (e.g. n-ary map) and can operate on different collections (e.g. `(map f <list> <vector>)`). Vincent [1] Unrelated to Clojure's transducers. I picked the name before they were announced. I'm open to naming suggestions. [2] The library is currently backwards compatible for all operations except `member`, whose current design doesn't make sense for indexed datatypes, and is an IMO questionable pun anyway. The library instead uses `member?`, which takes a failure thunk, and is thus closer to other, more modern Rackety APIs. ____________________ Racket Users list: http://lists.racket-lang.org/users
