#1218 what is the utility of porting it separately on .NET

ashishwave Sun 19 Sep 2010

Already iKVM is there ,which runs jvm programs on .NET /Mono. Infact Mono even bundles iKVM with itself and it is well established.

Hence you do not need to separately keep a .NET code base. all the java classes and .NET classes are available on iKVM (except swing and audio classes)

Hence, if you put your Fantom Core API even based on java, then it will be automatically be available on:

Fantom running on java
Fantom running on Mono/.NET using iKVM

May be, IMHO it would have been better reward for effort to give output to nekoVM or some sort of translation to C++ , just like haXe language has done

HaXe compiles to Javascript/Flash/PHP/C++/Neko etc (no Java) Whereas Fantom runs on Java/.NET/Javascript. (no nativeness like C++ )

Can't we have one language where we get all these advantage. May be separate .NET effort can be scrapped (and maintained via iKVM) and effort can be put to first decide on which platforms (native or other VMs) it can be redirected.

helium Sun 19 Sep 2010

IIRC somebody started a LLVM backend. Not sure though.

ashishwave Sun 19 Sep 2010

or may be, explore to target to http://llvm.org/

which gives you at once

http://vmkit.llvm.org/   (jvm and .NET target- though not mature)
http://libcxx.llvm.org/  (c++ target, this is what i am talking about)
etc

though haXe effort

ashishwave Sun 19 Sep 2010

oops! somebody already mentioned llkvm. What i meant to stress is that it should be easy to target somekind of fantom highlevel bytecode(not the fantom lower level byte code), say fantom-0 to target to parrot or llvm or nekovm easily or jvm.

increase the VM support (atleast on priority to C++(native) or syntax translation to PHP(say) by the core team

and then let us (the users) implement rest API stuff of fantom in that target language. An for that to happen you need to drop the repetitive work of implementing on .NET(when iKVM already facilitates)

katox Sun 19 Sep 2010

771 is the original LLVM topic.

DanielFath Sun 19 Sep 2010

Yes, duplication of effort does seem kinda pointless. On the other hand maybe Andy and Brian have some a different vision/plan for Fantom? My bet is that they simply needed something which compiles to .Net and Java independently and fast, so they went for a simple and fast interpreter instead of looking for Neko/iKVM.

brian Mon 20 Sep 2010

Here are some thoughts on this topic...

We didn't design Fantom to be a JVM language or a .NET language or a browser language. We designed it to be its own environment, but to target different runtimes. The JVM runtime gets the most attention, because I believe it is currently the best VM technology out there. But there is nothing guaranteed that will the situation five years from now. In fact given the current progress of JDK 7, one might easily see a future where the JVM isn't the best runtime.

When we started Fantom in 2005/2006 we considered that the two primary runtimes were JVM and .NET. I actually still believe this to be true, although we also consider the browser an equally important runtime. You could pull in dependencies like iKMVM to solve the problem. But to me that is akin to saying a Windows program is portable to OS X only if you run Parallels or VMWare.

Although the .NET implementation isn't really production ready, it fulfills a very important purpose - it keeps us honest. Because we maintain the .NET runtime of Fantom, we guarantee that Fantom is truly independent of the JVM runtime. All the APIs, native facilities, build tools, etc are designed from the ground up to support heterogeneous runtimes.

Because we did all that work upfront for .NET, we were able to add JavaScript support without changing much of the core design. And likewise, adding new runtimes should be equally possible. For right now the situation is that JVM and JavaScript are critical to our commercial business, so that is where Andy and myself focus. We maintain the .NET runtime to just make sure the basics work.

I would be happy to work with anyone else who had new runtimes they wished to target. If we did another one ourselves, most likely it would be iOS iPhone/iPads (especially now that the language restrictions have been raised).

Login or Signup to reply.