ClojureCLR VS Roslyn

Before Rich made Clojure for the JVM, he wrote dotLisp[1] for the CLR. Not long after Clojure was JVM hosted, it was also CLR hosted[2]. One of my first experiences with ML was F#[3], a ML variant that targets the CLR. These all predate the MIT licensed .net, but prior to that there was mono, which was also MIT licensed.

1: https://dotlisp.sourceforge.net/dotlisp.htm

2: https://github.com/clojure/clojure-clr

3: https://fsharp.org/

Yea, that's true. I forgot about that. I did think of Clojure CLR, but I don't get the impression that this is an all that natural or used implementation. ClojureScript is obviously much more used, although it is still a "different" language.

https://github.com/clojure/clojure-clr

ClojureCLR can already run on .NET 5.0 , so at least it made it through the .NET Core migration. I'm sure they'll get it to 6.0 at some point.

https://github.com/clojure/clojure-clr/wiki/Getting-started

I recently found there was a clojure implementation for .NET and also one for the BEAM Virtual Machine. Has anyone used the latter? Regards

[1] https://github.com/clojure/clojure-clr

Maybe it's not exactly a scheme, but there's Clojure CLR and it's actively maintained: https://github.com/clojure/clojure-clr/wiki

https://github.com/clojure/clojure-clr/commits/master

C# has COMEFROM, too: https://github.com/dotnet/roslyn/blob/main/docs/features/int...

they make it cumbersome to use by hand, but not impossible

>> It is not a compiler error. It is never a compiler error (2017)

No, not always true. Even in modern compilers -- as matured and as modern as VS 2022-- you would still get bug.

I found one[0]. In my case it's easy to tell it's a compiler bug because the program just can't compile properly. But it's also not easy to reproduce, which just proves how well tested compilers usually are.

0: https://github.com/dotnet/roslyn/issues/74872

MSBuildLocator for .NET Framework can only search for MSBuild 15, 16, 17 (Visual Studio 2017, 2019, 2022). So, if a user has a fairly old project and is using Visual Studio 2015, Roslyn won't be able to find a suitable MSBuild. Even if the project is fully built on the system, Roslyn simply won't work. We've reported this issue on GitHub. To cut a long story short, the devs don't prioritize it, citing that VS 2015 and earlier versions are just outdated. However, it turns out that if the user has the .NET SDK, Roslyn starts using a backup plan. If you have a .NET Framework legacy project, Roslyn will try to use BuildHost for .NET Core. Most of the time, this works fine, but issues can occur if there's something that isn't supported by MSBuild for .NET Core. You'll see this in the description of the third issue.

C# extension works well and uses Roslyn Language Server that is part[0] of the Roslyn (C# compiler) - this is what the base C# extension[1] uses. Both of these are licensed under MIT.

The only closed-source component is 'vsdbg' which is Visual Studio's debugger shipped as a component that the extension uses. It, however, can be replaced with Samsung's 'NetCoreDbg' by using the extension fork[2].

[0]: https://github.com/dotnet/roslyn/tree/main/src/LanguageServe...

[1]: https://github.com/dotnet/vscode-csharp

[2]: https://github.com/muhammadsammy/free-vscode-csharp

see also: https://github.com/dotnet/roslyn/pull/7850

The .NET runtime[1] and C# compiler[2] are both pretty easy to embed.

[1] https://learn.microsoft.com/en-us/dotnet/core/tutorials/netc...

[2] https://github.com/dotnet/roslyn/blob/main/docs/wiki/Scripti...

The C# compiler has an MIT license and is available on GitHub, which is about as FOSS as it gets.

https://github.com/dotnet/roslyn

My understanding is that the .NET team is working toward this with Interceptors: https://github.com/dotnet/roslyn/blob/main/docs/features/int...