Support F# expression in debugger eval

[enricosada]

To support F# expressions in debugger eval (watch/etc) need an F# expression evaluator

A sample evaluator https://github.com/Microsoft/ConcordExtensibilitySamples/wiki/Managed-Expression-Evaluator-Sample

As per info by @gregg-miskelly (debugger team) in https://github.com/OmniSharp/omnisharp-vscode/issues/1257#issuecomment-284833130 i quote directly because good ihmo (is already language agnostic, easier to do than before, debugger team may assist a bit to start)

For supporting F# expressions - someone would need to develop an F# expression evaluator. There is a sample expression evaluator on https://github.com/Microsoft/ConcordExtensibilitySamples/wiki/Managed-Expression-Evaluator-Sample. It used to be really hard to make a good EE, so the F# team and community never tried to make one (to my knowledge at least). It is certainly not something that someone is going to bang out in a week, but it is way easier than it used to be, so it would be great if someone from the team or community took that on. We are happy to provide some assistance in getting started / when folks get stuck. But it isn't something we have the resources or F# expertise to implement ourselves. Our model is that we provide the language-neutral infrastructure and language teams write the language-specific portions.

[cartermp]

Tagging - we're still in the process of figuring out things internal w.r.t teams and what they're working on, but this is something we care deeply about and will be looking at. Just a note, it's a considerable amount of work. A proper EE for F# will take time to complete and get right.

[KevinRansom]

@enricosada An F# aware EE would be a fantastic thing ... with the roslyn EE it may not be quite the humongous work-item it would have been in the past.

We are working through what it would take to make this happen internally, or what it would take to enable the OSS community to drive it.

Kevin

[saul]

Gregg's comment is promising. Looking at the API it doesn't look like it would be insanely difficult - considering some of the Roslyn features that have been written from scratch over the past few months this should be simple :p

[enricosada]

I just logged this as todo because the sample is really well documented. Can be useful later

[dsyme]

We should consider what the necessary entry point to the F# compiler service is. The signature needed will be something like this:

FSharpProjectOptions * fileInProject:string * locationInFile: Position* expressionText:string -> FSharpExpr

though some additional context may be needed to bind names, work out NameResolutionEnvironment etc. Walking FSharpExpr and doing evaluation is likely not too hard.

[dsyme]

For future reference: the C#/VB expression evaluator is here: https://github.com/dotnet/roslyn/tree/main/src/ExpressionEvaluator

[dsyme]

Chat with @tmat

[21:33] Don Syme
A while back I wrote an interpreter for some of F# here https://github.com/fsprojects/FSharp.Compiler.PortaCode, sitting on top of FSharp.Compiler.Service.  Perhaps that's the core of what's needed

[21:34] Tomas Matousek
The debugger has IL interpreter used for EEs. F# shouldn't need a custom one.

[21:34] Don Syme
I see, so it's an Expression -> IL compiler

[21:35] Tomas Matousek
Kind of. It's not really limited to expressions. That's just C# limitation.

[21:35] Don Syme
What if classes are needed for a construct (lambdas, object expressions etc)?

[21:35] Tomas Matousek
You can compile any code. The result is an assembly that gets interpreted.

[21:36] Tomas Matousek
Yes, that's allowed.

[21:36] Don Syme
Ah ok, is the assembly dynamically disposed?  Also is it out of proc with C#?

[21:36] Tomas Matousek
The assembly has a well-known entry point that the debugger runs

[21:36] Tomas Matousek
Currently in-proc.

[gregg-miskelly]

@dsyme For more information, the EE documentation is here