-
-
Notifications
You must be signed in to change notification settings - Fork 62
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Propose a design for generic lists #351
base: master
Are you sure you want to change the base?
Conversation
A few scattered thoughts:
|
Sure. Alternatively, we could translate it to
There is no
Maybe. We've certainly got the option to try it in the future. I'd like to get more done before exploring it though, since mutable collections and non-list collections might complicate the picture significantly. |
This is ready for review now. |
One question I have is about |
It will, in the form of a |
The proposal should make clearer that In retrospect, if This seems like a significant performance challenge right at the start, since not using Racket lists is likely to impose a cost (relative to Racket) on most programs. I had previously imagined that multiple |
More generally related to what @mflatt said, I think we need to be aware that most of the models we've considered for collections generally are in typed languages with compilers (often the JVM) that can eliminate more of the cost of dynamic dispatch and particularly wrappers relative to what Racket can do. We may need to consider different collections of tradeoffs than those systems ended up with (such as different choices about equality). |
This builds off #201, #221, #259, and #330, providing a more concrete design and plan for a generic interface for immutable lists. Currently still in draft status.
I'm working on this with @OxSon, who is handling most of the RRB tree implementation and benchmarking.
Rendered