-
Notifications
You must be signed in to change notification settings - Fork 847
[WIP] Fuse Seq.* calls #3233
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
[WIP] Fuse Seq.* calls #3233
Conversation
|
This is good. I personally prefer to always have chain separate |
|
Another important thing here is that fusion would also work on fable projects |
|
@forki is this going to remain wip, or should it be closed? |
|
Would love to get it in, but @dsyme is not a fan. So I'm closing it. |
|
@dsyme, merely for my education, could you clarify the reasons this should not be pursued. Thank you, Kevin |
|
@KevinRansom With very, very few exceptions we don't hand implement optimizations on a library-function-by-library-function basis - we look for general approaches like improvements to From the discussion of #1525
|
I think the general approach has already been suggested: Make the compiler extendible in that direction (ie. allow user defined optimizations). This way "FSharp.Core" is not "special" but everyone can do it for their own library as well. |
|
I agree with the reasons @dsyme explained. So, an alternative could be to be able to decorate some functions with attributes that allow to generalize these kind of optimizations. I don't have a detailed proposal in mind at the moment, but for example something like a |
|
@forki I'll close this per my reasoning above |
I really want to discuss #1525 again. We closed it because of RTM preparation.
I know there are related efforts to improve the underlying seq implementation. I think both can work well together.
This PR enables the compiler to rewrite
into:
Future rules:
Important point is that we always rewrite things to "smaller" terms so that we know it will terminate.