Open voronoipotato opened 1 year ago
Its like rewriting code to add support for F#. Even if added, then folks for more, like visual basic, J#... and alot of bugs and harder to concentrate. lol
Instead I suggest developers to do something like dnspy does. It de-compile .net byte code, and then generates equivalent code in C# and VB. Even code becomes more readable if pdb symbols are present.
So bflat can do following way:
That way you don't need to fight different language packs. Any .net executable whether C#, VB, F#, IronPython etc can be converted to native code without really need to add support for each. Just sharing some thoughts, rest author know well.
VB should have no issue exclusively running C# libraries, you need language support F# because the F# core library is different from the C# core library. The IL support is probably how we will do it, though you should not need to compile to C#. The good news is it will not lead to more bugs in the C# code since it is completely separated and will be maintained by F# devs. VB is the only other big language that may want to compile to native and their language is in most respects extremely similar to C#. It probably isn't going to be much work for them to add it if they put their mind to it.
The way forward with F# is to create a library project and pull it in on your C# executable.
I tested a simple function using this method
The way forward with F# is to create a library project and pull it in on your C# executable.
I tested a simple function using this method
Do you mind sharing what you have? Would love to see an example.
I'm not using this issue to push the creator to support F#. This is for the F# community to figure out if this is something that any of us are interested in working on testing/implementing. Also to track what needs to be done or changed to get it working. I personally think the zero version could be very compelling for F#.
Considerations