I suggest you ...

Implement 'Compiler as a service' for F#

It would be a tough blow for F# adoption to not provide 'Compiler as a service' when VB and C# does.

522 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Robert JeppesenRobert Jeppesen shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →
    completed  ·  Visual Studio teamAdminVisual Studio team (Product Team, Microsoft) responded  · 

    Our recommendation for Visual F# Tools users requiring a “Compiler as a Service” component is to use and contribute to the F# compiler service component at http://fsharp.github.io/FSharp.Compiler.Service/. This is also available as a Nuget package. This implementation is directly adapted from the open source code for the Visual F# implementation.

    The component is already used by numerous projects including the Visual F# Power Tools, FSharp.Formatting, the Xamarin and Emacs editing bindings for F#.

    We also encourage (and would like to contribute to) discussions about implementing Roslyn interfaces using the functionality available in the FSharp.Compiler.Service project.

    Don Syme, answering on behalf of for the Visual F# Tools team

    17 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • Visual Studio teamAdminVisual Studio team (Product Team, Microsoft) commented  ·   ·  Flag as inappropriate

        Our recommendation for Visual F# Tools users requiring a "Compiler as a Service" component is to use and contribute to the F# compiler service component at http://fsharp.github.io/FSharp.Compiler.Service/. This is also available as a Nuget package. This implementation is directly adapted from the open source code for the Visual F# implementation.

        The component is already used by numerous projects including the Visual F# Power Tools, FSharp.Formatting, the Xamarin and Emacs editing bindings for F#.

        We also encourage (and would like to contribute to) discussions about implementing Roslyn interfaces using the functionality available in the FSharp.Compiler.Service project.

        Don Syme, answering on behalf of for the Visual F# Tools team

      • Don SymeDon Syme commented  ·   ·  Flag as inappropriate

        Yes, from now on please see the FSharp.Compiler.Service project, which is a ocmmunity-led initiative to provide a compiler service for F#.

        http://fsharp.github.io/FSharp.Compiler.Service/

        This is sometimes called "Foslyn". The project is already widely used in a number of other F# community projects.

        We should ideally close this request so votes can be recycled.

      • Ryan RileyRyan Riley commented  ·   ·  Flag as inappropriate

        "By contrast, Roslyn gives us an API to compile code in memory, without ever having to launch another process, making things much faster. In fact, it is so fast that the incentive that we had to preserve compiled assembly in ‘Temporary ASP.NET Files’ mostly disappears."

        - http://blog.davidebbo.com/2011/10/using-roslyn-to-implement-mvc-razor.html

        That's what I want to see enabled. Is that possible today? I need to look at Fahad's recent transformation of the tryfsharp code to a library.

      • Ryan RileyRyan Riley commented  ·   ·  Flag as inappropriate

        It would seem to me the only thing missing, at least compared to Mono and Roslyn, is the ability to directly invoke the compiler within code. This seems more an alternative to the CodeDomProvider (or perhaps a more complete implementation) and similar to what ac and Laurent suggest. I don't see why we can't help with that effort since the CodeDomProvider and compiler are open source.

      • acac commented  ·   ·  Flag as inappropriate

        I read "compiler as a service" to mean the ability to run a program.exe and then have various non-compiled files/strings/byte arrays/streams that can be changed to modify the program behaviour without stopping the program.exe. You should be able to just click "save" in notepad and the program.exe will immediately start executing the new code.

        Further, it should be possible to strongly "scope" or at the extreme, sandbox what is possible to do in the non-compiled source easily. So that I can expose this service to users but limit what they can do with it. eg. prevent file/network/unsafe/pinvoke/limit access to only specified objects... etc.

      • Jon HarropJon Harrop commented  ·   ·  Flag as inappropriate

        I'd love to built better tools for F# but lack of compiler as a service makes this impossible.

      • govertgovert commented  ·   ·  Flag as inappropriate

        Perhaps the first step would be to ensure that the various Roslyn Language Service APIs are flexible enough to deal with the F# language too. Even if the production compiler is not Roslyn-based, having an experimental compiler that is and that could support uniform tooling in the IDE would be a big win. And that kind of feedback to the Roslyn team from a language that looks quite different could really help improve the APIs, which seems to be a major goal at this stage. The magic of F# type providers might come to C# at about the same time as the Roslyn compiler, so it would make sense to ensure the language service APIs will be able to deal with that - e.g. binding and type resolution need to work against the generated types. So I suggest you do enough to provide good feedback to the Roslyn team at this critical API review stage.

      • Johann DeneuxJohann Deneux commented  ·   ·  Flag as inappropriate

        I would have thought F# has had that for a while. There is a REPL, the source code of the compiler is available... What more is needed?

      • Don SymeDon Syme commented  ·   ·  Flag as inappropriate

        This seems to be a bit of a catch-all :-) So far in the comments it's covering (a) tooling extensibility (b) runtime meta-programming (c) hosting APIs (d) compile-time meta-programming, i.e. macros....

      • Vítor CastroVítor Castro commented  ·   ·  Flag as inappropriate

        Wouldn't this also be a better/alternative way to manipulate quotations in scenarios such as remote code execution?

      • Robert JeppesenRobert Jeppesen commented  ·   ·  Flag as inappropriate

        What I was thinking of when posting this would be that F# could benefit from a lot of the awesome tooling that is sure to pop up when Roslyn is released, but I'm sure there are many others. I like Laurent Le Bruns suggestion.

      • Laurent Le BrunLaurent Le Brun commented  ·   ·  Flag as inappropriate

        I don't know what this suggestion is about, but I would love to embed F# in applications. People often use Lua or Python to script the games and other software, I believe F# could do very well in this area (and give better performance).

      • Don SymeDon Syme commented  ·   ·  Flag as inappropriate

        Which specific adoption scenarios do you think would be most by improved by supporting more compiler APIs? Design-time tools? (i.e. Visual Studio add-ins) Or hosting? Or...? thx. don

      • Mike KMike K commented  ·   ·  Flag as inappropriate

        @Rickasaurus What kind of macro support are you talking about? Has there been any indication from the F# team that macros are coming to F#?

      • RickasaurusRickasaurus commented  ·   ·  Flag as inappropriate

        What if it had Type Providers and Macros instead? Are there any use cases those don't cover?

      Feedback and Knowledge Base