VisualFSharp VS Roslyn

Have you tried the workaround listed here? https://github.com/dotnet/fsharp/issues/12239

([email protected] bin)$ brew install --build-from-source mono ==> Downloading https://github.com/mono/mono/commit/3070886a1c5e3e3026d1077e36e67bd5310e0faa.patch?full_index=1 Already downloaded: /home/deck/.cache/Homebrew/downloads/77885651b42fb3b50e405e300ab4dce5d65e10eac8ee6b8d956b5240b58adcb3--3070886a1c5e3e3026d1077e36e67bd5310e0faa.patch ==> Downloading https://raw.githubusercontent.com/Homebrew/formula-patches/03cf8088210822aa2c1ab544ed58ea04c897d9c4/libtool/configure-big_sur.diff Already downloaded: /home/deck/.cache/Homebrew/downloads/195208ba31cadc265ea97bb8aad4e78caab1200daf4d855e6c839b5f987f92db--configure-big_sur.diff ==> Downloading https://raw.githubusercontent.com/mono/mono/a22ed3f094e18f1f82e1c6cead28d872d3c57e40/packaging/MacSDK/patches/fsharp-portable-pdb.patch Already downloaded: /home/deck/.cache/Homebrew/downloads/81c9245ab2b5c07a5bc87a8792e374b22a652c14be27b73aa21c1948f1273464--fsharp-portable-pdb.patch ==> Downloading https://raw.githubusercontent.com/mono/mono/a22ed3f094e18f1f82e1c6cead28d872d3c57e40/packaging/MacSDK/patches/fsharp-netfx-multitarget.patch Already downloaded: /home/deck/.cache/Homebrew/downloads/13d3ba5313c9e2b60ebfa4c40d5039269485e75aa41fcf301cc55458382fcb29--fsharp-netfx-multitarget.patch ==> Downloading https://github.com/dotnet/fsharp/commit/be6b22d11ae996b2d9b8e0724d9cf05ad65a0485.patch?full_index=1 Already downloaded: /home/deck/.cache/Homebrew/downloads/c3d6a94f53c828d6ad7b5a563682a6de3d388644f3a33f1ea55ec28fa461e24b--be6b22d11ae996b2d9b8e0724d9cf05ad65a0485.patch ==> Cloning https://github.com/dotnet/fsharp.git Updating /home/deck/.cache/Homebrew/mono--fsharp--git ==> Checking out tag v11.0.0-beta.20471.5 HEAD is now at 03283e07f Merge pull request #10172 from dotnet/merges/main-to-release/dev16.8 HEAD is now at 03283e07f Merge pull request #10172 from dotnet/merges/main-to-release/dev16.8 ==> Downloading https://raw.githubusercontent.com/mono/mono/3070886a1c5e3e3026d1077e36e67bd5310e0faa/packaging/MacSDK/fsharp-layout.sh Already downloaded: /home/deck/.cache/Homebrew/downloads/85ab59b70661632962989d0527aa31b2a720c49968d45f368ff0a1fa190159b0--fsharp-layout.sh ==> Cloning https://github.com/mono/msbuild.git Updating /home/deck/.cache/Homebrew/mono--msbuild--git origin/HEAD set to xplat-master refs/remotes/origin/xplat-master ==> Checking out revision 70bf6710473a2b6ffe363ea588f7b3ab87682a8d HEAD is now at 70bf67104 prevent exception for increasing priority (#5547) HEAD is now at 70bf67104 prevent exception for increasing priority (#5547) ==> Downloading https://download.mono-project.com/sources/mono/mono-6.12.0.122.tar.xz Already downloaded: /home/deck/.cache/Homebrew/downloads/6092400166df5dee225b09670c68fa3aa400319e8871facaff0106aa143419fb--mono-6.12.0.122.tar.xz ==> Patching ==> Applying 3070886a1c5e3e3026d1077e36e67bd5310e0faa.patch patching file packaging/MacSDK/fsharp-layout.sh ==> Applying configure-big_sur.diff patching file configure Hunk #1 succeeded at 10928 (offset 2195 lines). ==> ./configure --prefix=/home/linuxbrew/.linuxbrew/Cellar/mono/6.12.0.122_1 --enable-nls=no Last 15 lines from /home/deck/.cache/Homebrew/Logs/mono/01.configure: checking whether we are using the GNU C++ compiler... yes checking whether g++-11 accepts -g... yes checking dependency style of g++-11... gcc3 checking for a Python interpreter with version >= 3.2... python checking for python... /usr/bin/python checking for python version... 3.1 checking for python platform... linux checking for python script directory... ${prefix}/lib/python3.10/site-packages checking for python extension module directory... ${exec_prefix}/lib/python3.10/site-packages checking dependency style of gcc-11... gcc3 checking for gawk... (cached) gawk checking how to run the C preprocessor... /lib/cpp configure: error: in `/tmp/mono-20220328-41596-77f8ae/mono-6.12.0.122': configure: error: C preprocessor "/lib/cpp" fails sanity check See `config.log' for more details READ THIS: https://docs.brew.sh/Troubleshooting

It will be in here somewhere but you’d need to dig: https://github.com/dotnet/fsharp/

I know csharp got hot-reload for blazor for a while, I also keep tracking on the fsharp issue and hope there is some miracle which can happen. But there is no progress here. So I decide to have a look for what I can do. To make dotnet watch work directly is too hard to me which required a lot of knowledge about FSharp.Compiler.Service and the IL format which csharp roslyn is using for patch the program for hot-reload.

Better F# exception message formatting by default (same as if you override it and use %A) https://github.com/dotnet/fsharp/pull/12736

] toggle in F# https://github.com/fsharp/fslang-suggestions/issues/919#issuecomment-905013334 which can guarantee AOT/linker compatibility - Reference assembly output https://github.com/dotnet/fsharp/pull/12334

If you get a message like "warning FS3511: This state machine is not statically compilable." don't worry it is being tracked in https://github.com/dotnet/fsharp/issues/12038

You can simply contribute to https://github.com/dotnet/fsharp/, the maintainers are very friendly to new contributors in my experience (though the codebase is old and often quite hard to understand).

It looks like FSharp.Core 6.0 has been released on Nuget. However, I haven't seen an announcement and there's no mention of it in the current release notes. Is there any official information on this?

The F# Programming Language: I consider F# as the functional-oriented sibling of C#. This language offers a nice introduction to statically-typed functional programming. It offers a really nice ML-like syntax, as well as some features like type providers (a way to define a schema for data such as a database table, JSON file, etc.).

Honestly, I don't have a clue why these would be different. I found the relevant Roslyn code here. You can see on line 719 that this is definitely intentional:

compiler: https://github.com/dotnet/roslyn

Why not use Roslyn Scripting…you can pretty much do any kind of dynamic evaluation with this and it does not require any reflection. https://github.com/dotnet/roslyn/blob/main/docs/wiki/Scripting-API-Samples.md you can add the support via a Nuget.

It was discussed at one point: https://github.com/dotnet/roslyn/issues/5058

It must be a fairly large echo chamber since it has room for Clang, GCC, V8, OpenJDK, Roslyn, etc. (The Zend parser for PHP seems to use some flavor of YACC, but given PHP, I don't know if that strengthens or weakens my point.)

I'm planning to rewrite all of our company's old T4-based codegen tools into Source Generators. I've been looking at how other Source Generators are implemented and what surprised me is that everyone seems to assemble the output code manually as text with string builders or at best some simple templating engine (eg. Scriban). I expected that I would see a lot of projects assembling their output code from Roslyn tokens and then using Roslyn's formatter to produce the actual code that can be emitted into the output file(s), like this article demonstrates. No-one seem to be doing that though. Why?

Clearly nobody ever manages to use this Go thing with over 700: https://github.com/golang/go/issues. Or .net, over 5000 issues for the compiler alone: https://github.com/dotnet/roslyn. I'd guess stuff like Java, glibc would be similar if they used github

Looking at the github history of the string holes feature, it looks like it was actually a simplification that had the side-benefit of generating a bloggable feature. There was a lot of code that existed solely to prevent holes inside string interpolation and the change was to remove that special casing. The core change to the parser is almost entirely deleting lines https://github.com/dotnet/roslyn/pull/56853/files