What does Visual F# IDE Tools using Roslyn Workspaces mean for the future Visual F# Powertools and Ionide

[cloudRoutine]

As per the discussion in #913 there seems to be a lot of confusion over what this shift means for the future of the community based F# tooling

Now the architecture that seems to have a lot of community support behind it (long advocated by @7sharp9)

[ Fsharp Roslyn Tools] [ Fsharp-vim ] [ Ionide ] [ Fsharp Xamarin ]    [ etc ]
            |_______________|_____________|______________|________________|
                                          |
                                [ FSharp Powertools Core ]
                                          |
                                [ FSharp Compiler Service]

also referred to by @dsyme in

• How to take forward the prototype of a Visual F# editor based on Roslyn #913 (comment)
• How to take forward the prototype of a Visual F# editor based on Roslyn #913 (comment)
• update FCS to 2.0.0.2 fsprojects-archive/zzarchive-VisualFSharpPowerTools#1317 (comment)

I think another long term benefit of taking this approach would be merging the cross-platform editor agnostic power tools into the compiler service to make by far the most powerful language service out of the many functional programming languages.

I think some of the pertinent issues to address are -

• How will tooling based on Microsoft.Diagnostics APIs be implemented? Will they be baked into the VS integration or exposed in a manner that can be consumed by other services, e.g. as a part of the FSharp.Powertools.Core model or something else?
• Will just the VS Shell related functionality of VFPT be subsumed or is the intention to subsume the project in its entirety?
• How will moving to this Roslyn effect the implementation of new F# specific functionality in VS that doesn't fit into the Roslyn workspace model?
• Will moving to the VFRT model lock in the addition of new features to the Visual Studio update release schedule?
• In the case of VFPT being broken up into a "plugin" model will the VSRT be designed to accept plugins designed in a VS agonsitc manner or should we expect VS API lock-in?
• Will moving to an Omnisharp model be a competitor to the current Ionide tooling?
• Is there really any benefit to using Omnisharp at all?
• What priority will the Omnisharp team put on implementing features for F# over currently missing C# features? Will there be any room for F# specific features?
• Is Ionide going to be relegated to doing only community library/tooling integrations?

@tpetricek has suggested it might be fruitful to have a google hangout (or skype) discussion about this to hash out a plan for the future of F# tooling moving forward

@KevinRansom @NumberByColors @dungpa @vasily-kirichenko @Krzysztof-Cieslak @forki @nosami @rneatherway

[nosami]

Will moving to an Omnisharp model be a competitor to the current Ionide tooling?

Yes (unless they join forces)

Is there really any benefit to using Omnisharp at all?

Not that I can think of. Cross language goto declaration and find references could be a possibility, but that could also be achieved in other ways.

What priority will the Omnisharp team put on implementing features for F# over currently missing C# features?

I'm no longer involved with Omnisharp stuff so can't speak for the others

Will there be any room for F# specific features?

The last I knew, different features could be implemented for different languages. Paging @david-driscoll for clarification.

[KevinRansom]

@cloudRoutine, it is very early to answer these questions, we don't have a firm design, we do however, understand how the integration with Roslyn will look, because that was the purpose of the prototype.

Obviously the Roslyn Team are in fact our team mates therefore we are in a good position to ensure that the APIs exposed by Roslyn will work well for us.

Roslyn committed to OmniSharp at the time that VSCode was announced. We expect to be able to leverage that work for the F# Tooling it's not that we think one way is better or worse than any other, it's just that a decision has been made and we intend to leverage the work of other members of our team. to make roslyn workspaces and Omni sharp work.

Our expectation is that the VFPT team will continue to develop the power tools separately from us. We do not want to get in the way of the great work that they are currently doing. However their integration into VS will be different from how it is now. Because the language service underneath the editor will be completely different.

It would be fair to say that as of right now we have no design for how these pieces are going to be integrated, or what the issues are going to look like after they are integrated. But once we have a better understanding we will be able to itterate on designs.

It is not our goal to undermine the great work done by the VFPT team, Xamarin or anyone else. What we do intend ensuring is that our tooling gets unstuck from the unsupportable mire that it is currently in.

[dsyme]

However their integration into VS will be different from how it is now, because the language service underneath the editor will be completely different.

AFAIK VFPT has very few dependencies on VFT.

• There is one small dependency on the VFT language service - a minor hook related to understanding tokenization states for tokenization information at the end of each line in a buffer. But I think that can be dealt with.
• VFPT has one minor dependency on the existing F# project system to get project setting accurately. But the F# project system that is not changing with this work.

So I suspect there will be ways to just keep VFPT working.

[dsyme]

... Omniisharp... .multiple editor....

I suggest we put aside all talk of multiple editors when discussing this work, at least for the next few months. This is about revamping the Visual F# Tools using the Roslyn Workspace APIs for Visual Studio, period. And taking a community-oriented approach to it right from the start.

Whether this can be reused in other future editing contexts is somewhat irrelevant: the work is worth doing simply to make the Visual F# Tools better.

F# has existing strong support and momentum in a whole range of editing tools. That should continue exactly as is. And this effort will leverage the shared components coming out of that work (e.g. the FCS APIs and likely FSharpVSPowerTools.Core).

So for this work let's just focus on Visual Studio for now.

It's just as if the Xamarin F# support was reimplemented on some new Xamarin API, or the Atom F# support was implemented on some new Atom API.

[Krzysztof-Cieslak]

As far as I understand all "problems" and "confusion" in Ionide part were prompted by information about adding F# support to Omnisharp, what has nothing to do with VS, and would have huge implications for F# plugins for other editors. But I would love to get "official" point on that - since it's another thread where Don is saying focus on VS, while Kevin is also mentioning Omnisharp. Also, if F#/Omnisharp integration is planned, we should not ignore it right now and figure out later, after few months since it's important to ensure that all those LEGO pieces will work well together.

To the VS topic:
I still believe, that proposed by @cloudRoutine "architecture" (with possible future merging of FPT.Core to FCS) is best solution, as it would help whole community, and would allow to unify higher level features into one project instead of 3 different implementations we have right now (VFPT, Xamarin, FSAC). And I think it should be implemented anyway, but it would be nice if it was also used by this new API for VS.

[dsyme]

My understanding is that the mention of Omnisharp was aspirational, in the sense of "if we do this perhaps we could do that later" sense. It seems an awfully long way off if you ask me: there is no active work in this space. @otawfik-ms is only just getting up to speed and there's a long way ahead for just the VS tooling alone.

Re the VS topic: Yes, I think bringing FPT.Core into FCS would be appropriate. My understanding is that FPT.Core is effectively used as an add-on to FCS. @otawfik-ms has said he is studying the relevant designs.

[7sharp9]

What we need is simply an agnostic editor core, if work is furthered on that front then everyone will benefit.

What tends to happen is everyone says yeah lets do that, then goes ahead with separate solutions which patch around the bugs/issues/caveats in the compiler etc.

I think a reasonably thorough discussion of what a reusable agnostic editor core is would be useful, especially getting feedback from current major users like ionide, emacs, monodevelop, vs, vfpt. A formal RFC discussion like what happens for rust may be useful, organisation around any compiler related tooling advancement has always been rather fuzzy.

[dsyme]

@7sharp9 Commonality is very useful, and may continue to arise naturally out of projects like this.

However I think it's very important to realize that this is not what this work is about. Microsoft have limited resources and the immediate task is to lift the Visual F# Tools off the VS COM interfaces (and the ancient FSharp.LanguageService.Base) and onto the Roslyn workspace APIs. This doesn't need a common editor core since it nearly all sits directly on FCS (plus some of the implementation of FSharp.LanguageService which must presumably be brought over). @otawfik-ms and contributors will need to focus on that engineering rather than being faced with the much larger and more daunting prospect of redesigning and coordinating a common core right across all editors.

So I guess I'm asking that for now we allow this work to focus on the localized needs of the Visual F# IDE Tools, rather than becoming a cross-editor design discussion.

[dsyme]

Closing old discussion