Do you have any plans to support F#? Are you open to community contributions for such support?
Hi Ryan,
We don’t have any concrete plans at this stage for new languages, right now our priority on that front is to finish Mercury/VB, and then we’ll see what’s next. If and when we do add a 7th language, F# is definitely on the list of (handful) languages that might be interesting.
In theory, yes, but I’m afraid I’m nt stir now practical this would be for the core compiler support, as the core compiler is closed source. That said, we recently did abstract this a lot in terms of separating the individual languages into dedicated .dll projects, so that might actually open up the possibility for doing new languages in such a way — I haven’t really thought about this before TBH, so I’ll have to look at the feasibility in more detail, and run this by the compiler team.
Fi we get to do F# (or for the other languages as well), community contributions are certainly welcome in Rothe areas of the tool chain, especially (but not limited to) Templates, Samples, Test Suites, etc.
thanx!
marc
1 Like
One vote from me for F#/Island
I don’t see much point of re-inventing the wheel for F#/.NET, given Microsoft’s F# compiler is already open sourced, and well established.
-
But maybe (?) it is a good selling point to mix C# and F# source codes, like mixing RemObjects Oxygene, Swift, Go, C#, Java all at source code level within one project.
-
MS/C# and MS/F#, does not support mixing C# and F# source code file in one project, while C# can only interop with F# via compiled assemblies, which is a headache.
But I personally don’t care much on the .NET side. The best I would expect (or dream of?) is to have a native LLVM-based F#/Island compiler. That would certainly attract (I assume) OCamel developers.
1 Like
That is exactly the reason I’d like this!
2 Likes