Package/DotNet Interactive

[krauthaufen]

Hey all,

I recently copied large parts of FsAutoComplete.Core to dotnet-interactive in order to get hover-texts.

Basically this works fine, but there are two major problems:

1. I needed to copy the code and get rid of several dependencies (ProjInfo, etc.) since interactive already knows these things internally.
2. FSharp.Compiler.Service needed to be replaced with FSharp.Compiler.Private.Scripting (which I presume will be a non-issue in the future?)

So I wondered if there was a way of integrating FsAutocomplete's awesome hover-texts, etc. in a more maintainable way. (Currently all changes here would need to be reflected in dotnet-interactive)?

Any Ideas?

[cartermp]

The dependencies in the kernel would have to change to ultimately allow for this. As a temporary measure, porting source code is probably fine. But in the long-term there's change involved on the .NET Interactive side of things before it can incorporate FSAC as a package.

[dsyme]

We do need to be consolidating the signature formatting code I think. We can't proliferate it further, especially into codebases where there may or may not be F# expertise (e.g. Jupyter kernels)

One way would be to move it into FCS itself I guess (so it appears in both FSharp.Compiler.Service and FSharp.Compiler.Private)

I need to get understanding for how polished and tested is the signature formatting code here and how much it improves over FCS formatted signatures.

This also relates to fsprojects/FSharp.Formatting#547 which I've got a TODO to help push through.

@krauthaufen This may take a while to work out, but I think it will be worth it in the end.

[cartermp]

I would personally love to see the tip formatter moved into FCS proper and I would happily wire it up to VS (provided the VS tooltip infra doesn't make it look awful 🙂 )

There would definitely be a feature diff involved and what some folks might view as a regression. But it's worth exploring.

[krauthaufen]

One way would be to move it into FCS itself I guess (so it appears in both FSharp.Compiler.Service and FSharp.Compiler.Private)

Maybe wo could add something like

tryGetSymbolInfo : CheckFileResults -> Position -> SimpleSymbolInfo option

which in turn has something like SimpleSymbolInfo.toPlainTextToolTip : SimpleSymbolInfo -> string and maybe SimpleSymbolInfo.toMarkdownToolTip : SimpleSymbolInfo -> string.

With (the yet-to-be-designed) SimpleSymbolInfo users could then query source-information for various purposes easily without needing to dig into FSharpSymbolUse and other things.

I'm thinking something along the lines of:

type SimpleSymbolInfo =
    { 
        Name : string
        Documentation : string option
        Kind : (Value of TypeInfo | Record | Union | Class | Property of DeclaringType | ... )
        DeclarationLocation : Range
       // ...
   }

What do you think?

[baronfel]

I'm totally in favor of pushing down parts of FSAC into FCS proper; I've always thought of this library as sort of an incubator for editor services :)

I also like the idea of having an intermediate representation of the relevant information for a symbol, and converter functions to various formats. That seems like a good way to leave things open to extensibility/experimentation without having to make changes to FCS all the time.

[cartermp]

@krauthaufen if you're interested, I'd be happy to review a PR that adds the formatting code to FCS. It sounds like we all want to do it, it's just a question of the shape of the API and testing. That can be worked out in a PR without too much bikeshedding :)

[Krzysztof-Cieslak]

What would be the value of this new type over FSharpSymbol? I mean yes, it’s fairly complex type and not super friendly to use... but that’s just because it represents complex concept with lot of information - and this information is crucial when working on editor tooling. I’d be careful about adding additional abstraction layer if in practice no one will use it because lower layer will be needed for any real world scenario.

That said I’d welcome APIs like CheckFileResults -> Position -> FSharpSymbol - and not only for this API but for many more. I never understood why we expose APIs that get things like lineStr or identIslands. I mean, I understand technically why those are needed but I believe exposed API should handle that under the hood and be more streamlined.

Also regarding the tooltips itself - I think FSAC/Ionide has the best tooltips out there - formatted signatures, more information from xml docs than VS ones - but I think it would require whole bunch of work to make it VS-level acceptable - there are definitely bugs in there (especially in signature generation and formatting code)

[krauthaufen]

I think for people working with FCS a lot FSharpSymbol is just fine but for others (including myself) it's just too complicated and tasks like filter the members shown in the hover-text or don't show the defining assembly name require changing the hover-text code. Things like these could be greatly simplified when working with a first-class info-type (e.g. a record where I can just do something like { info with members = List.filter ...})