#2748 Any consideration for dotnet-core?

Ilove:= Sun 16 Jun

Just wonder if the devs interested in it. I myself don't ask fan for supporting it :)

SlimerDude Sun 16 Jun

The issue with creating any new native target is, due to the way Fantom has been structured, the entire core sys library needs to be re-written in native code for that target.

Doing this makes for an optimised and speedy core, but it is also a MASSIVE undertaking. It's also a good part of the reason why the .NET branch has fallen so far behind, for it's just not just about creating the target, but actively maintaining it to keep the native implementation up to date.

A feature I've always said would be neat (and something that I think Go4 has done with FanX) is the ability to write the Fantom sys pod, in Fantom.

Some parts of sys would always need to be written natively, such as File handling and anything IO related. But large swaths of Fantom sys are just basic methods doing basic data manipulation (like all these new methods Brian likes to add to List!) and keeping multiple targets up to date then just becomes tiresome.

But if Fantom could in large be written in Fantom - then the footprint for new native targets is much smaller and becomes more attainable.

This obviously shouldn't preclude sys from being completely written natively - as we wouldn't want to loose the awesome Java and Javascript runtimes we currently have!

Ilove:= Sun 16 Jun

I understand this, SlimmerDude. Implement a partial working new target is easy, but keep it up to speed is hard, especially in the dotnet case, MS is moving it so fast, even my beloved SharpDevelop can't keep up and the project discontinued. That's the reason why on my other thread I suggested remove the dotnet target completely and focus on nodejs :)

Ilove:= Sun 16 Jun

I think the only way fan could be written in fan is transpiler. Recently I spend a few days to test eclipse xtext but can't make anything significant. I just a very bad coder.

Ilove:= Sun 16 Jun

Xtext allow us to develop dsl language. Not a simple one like the tutorial below but also possible to create full featured language like Xtend lang. I tried to create a dsl language mimic a very small subset of pascal but can't get any far than print hello world using writeln. I think we could develop a dsl language with fan syntax and then it will transpile to Java and self-hosted :)

Ilove:= Sun 16 Jun

Xtext: https://www.eclipse.org/Xtext/documentation/102_domainmodelwalkthrough.html

Xtend lang: https://www.eclipse.org/xtend/documentation/202_xtend_classes_members.html#extension-methods

Ilove:= Sun 16 Jun

I don't know why this text field doesn't allow me to post as a whole long post?

Ilove:= Sun 16 Jun

I fear the power of DSL languages that I could spend an entire day just to learn another syntax and another syntax but can't be sure this syntax will relevant for how long before being abandoned and a new syntax rise up. And we call these syntaxes languages. The same problem happens with languages transpile to js. I've learned the wrong way. Instead of learning programming, I learn languages syntaxes. How stupid!

Ilove:= Sun 16 Jun

Anyway my idea still there, we could only write fantom in fantom if we use a transpiler. In this regards Xtext comes in handy, we will have to implement a DSL language with fantom syntax and called it fantom :)

Lii Sun 16 Jun

Maybe IKVM could be used to translate the Java bytecode of the Sys module into .NET bytecode?

That might significantly reduce the development effort that is needed to create and maintain a .NET target.

Ilove:= Sun 16 Jun

I already suggest using ikvm on this thread: https://fantom.org/forum/topic/2749

BTW, all of you have some confusion between dotnet and dotnet-core? Fan only supports dotnet, not dotnet-core. This thread is about asking the devs if they interested in adding dotnet-core support :)

Ilove:= Sun 16 Jun


Lii Sun 23 Jun

A .NET implementation for Scala apparently used IKVM for a while:


(Note that this information is really old.)

Ilove:= Mon 24 Jun

Scala.NET is dead now, unfortunately. IKVM is very stable for it Java 8 implementation. Support for newer Java is unlikely as the company that continued it development currently stick to Java 8. Fan itself also try to keep Java 8 support as long as possible.

There're so many people using IKVM that even suprised me about it popularity. For example: https://sergey-tihon.github.io/Stanford.NLP.NET/faq.html

I think if Fan doesn't have the man power to keep the dotnet port in good pace and doesn't want to remove it completely, using IKVM is reasonable :)

Login or Signup to reply.