At Sat, 7 Mar 2015 21:32:10 -0800, Alexis King wrote: > > So as it turns out, I have found myself sorely wanting generic > interface support in Typed Racket. I understand that the class/object > system seems to be the usual method of implementing interface-like > polymorphism in Racket, but I actually much prefer the style of > polymorphism that generics have to offer.
FWIW, so do I. IMO, the transition from functions+structs style to structs+generics style is smoother than to methods+objects. It would be nice to also have a smooth structs+generics to methods+objects transition, but I don't know how that would work yet. > Supporting the full set of features generics have to offer is a fairly > daunting proposition, so obviously I’d want to work on getting a > useful subset of the features instead. As far as I can tell, this can > be subdivided into a set of smaller goals. > > The simplest implementation would be one that would only work within > typed code, would only work on structs that explicitly implement the > generic interface, and would not support #:defaults of any kind. I think it may be easier to start with the "`require/typed` untyped interfaces" route. That way you avoid having to deal with typechecking `define-generics` forms for now. I think that may also get you a good portion of the use cases. It would be possible to implement and use existing generics (e.g., `gen:set`) from TR, and new generics for use in typed code could simply be defnited in separate untyped modules and imported. I haven't thought much about the type system aspects of generics + TR, though, so it may be that the above plan doesn't actually simplify things much. Just my 2c. > I actually don’t care about this all that much because I don’t find > the use of generics to be very prevalent throughout existing Racket > code. Obviously, it would need to be implemented eventually, but I > would find immediate uses for generic support that would only function > within typed code. In fact, wanting to use generics in a personal > project of mine was what prompted me to look into this. I think the reason generics are not used pervasively is that they're a relatively recent addition, and that a lot of the "obvious" use cases would require retrofitting the standard library, which hasn't been done yet. (I hope to get to work on that this summer, but I need to finish my PhD first ;) ) > What I’m interested in finding out are some answers to the following > questions: > > For those familiar with Typed Racket’s internals and implementation, > how much of an undertaking does this appear to be? Would this be > completely out of my grasp, or would it even be worth my time to look > into? I'd say: go for it! :) I recommend you design the type system aspects first, then work on the implementation. It's easier to iterate on the design that way, and conceptual bugs should be apparent earlier in the process. I won't lie, this is probably not going to be easy work, but it would definitely be a good addition to TR, not to mention a major learning experience for you. :) If you need pointers/advice, feel free to ask Sam/Asumu/Eric/Andrew/myself. >From that group, Sam and Asumu are probably the ones most familiar with the relevant type systems literature, and can probably point you to papers with potential starting points. Vincent -- You received this message because you are subscribed to the Google Groups "Racket Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-dev/8761aadu7w.wl%25stamourv%40ccs.neu.edu. For more options, visit https://groups.google.com/d/optout.
