14 comments

Add a comment…

Sign in

prestine

Your email address

Check!

invalid email

(thinking…)

Reset

or sign in with

• 
• 

UserVoice password

Forgot password?

Create a password

Your name

I agree to the terms of service

Signed in as (Sign out)

Close

Close

Post comment Submitting...

• Ed commented  ·  March 1, 2013 10:48 a.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

  Make it work with code quotations as well please :)

• Ryan Riley commented  ·  March 20, 2012 9:20 a.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

  "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 Riley commented  ·  January 26, 2012 8:36 a.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

  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.

• ac commented  ·  November 12, 2011 3:46 p.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

  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 Harrop commented  ·  November 2, 2011 10:24 a.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

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

• govert commented  ·  October 21, 2011 2:50 a.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

  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 Deneux commented  ·  October 20, 2011 12:19 p.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

  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 Syme commented  ·  October 18, 2011 2:58 a.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

  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 Castro commented  ·  October 14, 2011 1:40 p.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

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

• Robert Jeppesen commented  ·  October 14, 2011 10:43 a.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

  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 Brun commented  ·  October 14, 2011 6:29 a.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

  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 Syme commented  ·  October 14, 2011 2:15 a.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

  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 K commented  ·  October 13, 2011 6:35 p.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

  @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#?

• Rickasaurus commented  ·  October 13, 2011 5:17 p.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

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