Consider managing FSI sessions in FSAC directly

[baronfel]

Managing sessions directly in FSAC would allow for more full featured treatments for features like the watcher, as well as serving as the foundation for notebook approaches.

There would be some book-keeping around identifying which evaluation session a particular interaction command would be associated with, so we'd want to spec out a small set of custom LSP endpoints specifically for dealing with this, but it would be possible to do something like:

• User sends line/selection/file to FSI session via custom LSP endpoint
• FSAC identifies the session by some kind of ID and performs the evaluation of the provided line/selection/file
• FSAC sends any output of the evaluation to VSCode for display
• FSAC extracts the session state after the evaluation using the session.GetBoundValues() API and returns that data to VSCode for display in a watcher (if open)

Originally posted by @baronfel in #1716 (comment)

[Krzysztof-Cieslak]

User sends line/selection/file to FSI session via custom LSP endpoint

I do wonder if there's some way of just redirecting stdio of the console app into the FCS-hosted FSI session so we keep the ability to type into the terminal.
This probably would mean that our "enhanced FSI" would be a separate process (i.e. not FSAC) but since it'd be used just for FSI-related things it shouldn't be too perf-expensive

[Krzysztof-Cieslak]

Proof of concept for the idea of just wrapping FCS-hosted FSI session into console app, it also starts HTTP server which can be used for getting the info about the session: https://github.com/ionide/Falcon/blob/master/src/Falcon/Program.fs

[Krzysztof-Cieslak]

CC: @jcmrva, it may be interesting for you

[AngelMunoz]

This might be kind of related, I've been looking today into the FSI watcher (mostly to test the waters and fun) and I found out it is very annoying to create webviews, would there be interest to also host FSI related Webviews in that out or process server?
I'm not too familiar with the code extensions API so I'm not sure if you can just use any URL but that would also give us an edge to use F# tooling for the website rather than just try to force strings for webviews

[jcmrva]

@Krzysztof-Cieslak I like it!

I do wonder if there's some way of just redirecting stdio of the console app into the FCS-hosted FSI session so we keep the ability to type into the terminal.

That would be ideal.

I'm hoping that could also address one of the unintuitive behaviors of the current implementation: sessions started in the terminal with dotnet fsi aren't recognized. One learns to use it correctly but it would be nice to make that seamless.

[Krzysztof-Cieslak]

This might be kind of related, I've been looking today into the FSI watcher (mostly to test the waters and fun) and I found out it is very annoying to create webviews, would there be interest to also host FSI related Webviews in that out or process server?

We can't really easily host webviews out of the process since they won't have access to CSS styling of VSCode - I guess we could probably hack around it somehow, but it doesn't sound trivial enough to justify the effort and potential complexity.