Compilation Model Prototype - Information / Discussion / Proposed Plans #7077
For the community: I wrote this up internally with some minor modifications since I have posted it here. I just need some feedback on what everyone's thoughts are. Is this something that the community actually wants out of F#? Do you think I should or should not spend more time on this before/after F# 4.7? Perhaps the community would be interested in contributing?
My purpose is to really figure out how to take F# to the next level, in terms of tooling, testing, memory and performance. Right now, I do believe this could get us there long term, but I also want to get us some short term gains in the process, namely our testing.
Here is the PR to the prototype: #6947
Hopefully what I'm talking about is accurate and informational. There are a lot of pieces to this, and so this is an entire brain dump from my head put in a post. I'm sure something will need to be corrected.
I realize that I need a plan regarding the work of the compilation model prototype and our goals for .NET Core 3.0 / F# 4.7 for 16.3 release. Prototypes in the past have always stopped and never continued. One example is the metadata reader re-write using System.Reflection.Metadata which we may re-visit but I didn't make any plans on how that may continue. I don't want the compilation work to stagnate this way while I focus my attention to F# 4.7. Instead, I want to figure out how the compilation model could tie in with our goals for 16.3.
I'm providing a few Q/As with descriptions of what led to where I am at now. After that, I will get into my plan and current state of the prototype.
Now, onto the current state of the prototype and a proposed plan moving forward.
Current State of Compilation Model Prototype
@auduchinok I think we eventually plan on moving this into FCS. Since there's going to be a long tail of bugs involved, we'll probably keep it separate for a while. We certainly wouldn't be using it in our own codebase until the quality is high enough, at which point we'd look to integrate with FCS so that all editors can use it. While it's separate I think it should be pretty easy to test, and we are intending on it being pretty easy to plug into an editor host so that you could dogfood it outside of Visual Studio. Its dependencies are portable so there shouldn't be an issue with that in theory.