Here are the notes for the brainstorming Andy and I did over at his place tonight...
Things that really really suck regarding in-line native code integration:
Requires almost full fidelity of the JVM and CLR type system and operations in both the language and in fcode
Adds immense complexity to the language - just lots of ugly things
Pretty much pins us Java/CLR
So then I started thinking about our original ideas to make Fan a portable language for other "VMs" - namely targeting JavaScript which is the VM in all browsers - it could be as important as Java or .NET in the end. Plus for the embedded world there could still be big value in running C++ code.
So that leads to the out-of-line solution, which has the really crappy stub/merge problem. How do I partially implement a Fan class in Java or C#, but still get javac or csc to compile against the full signatures? More importantly it almost certainly means that I loose my clean single fcode deployable pod - if I'm going to do the out-of-line solution then I'm going to have to deal with deploying both a jar and dll in addition to my pod file.
So talking thru these all issues, leads us to solution where maybe we skip the whole back-end compile step entirely. Instead fanc generates Java, C#, or JavaScript source code. Let's take the graphics module example, with a directory structure as follows:
The first subdirectory fan contains the pure Fan code. Graphics.fan would stub some methods using the native keyword. Then the java subdirectory would contain the Java native code. Graphics.java would be a partial class - maybe use the partial keyword like C# introduced. This partial class would implement Fan native methods and add it's own Java specific methods and fields. I could also include whatever Java support classes I wanted (in a pod like sys, these classes might represent the bulk of the module).
In this design, fanc's job would be to emit not fcode, but rather Java source code (or C#, JavaScript, etc). Fanc would still do all the front end stuff like parsing, type checking, etc - but emit source code out a pluggable backend. It would also act as a build tool merging native source files with the emitted source files, copying the support files, sticking in a package declaration, etc. Lastly it would call out to javac to compile to classfiles setting up the classpath for jars of the dependent pods.
We would still need to generate something akin to a pod file which represents the pure Fan signatures for type checking (but probably not with fcode method implementations). Likely though this information would be embedded into the jar or .NET DLL since it is needed for reflection anyhow. Maybe we just always use jars for this purpose.
But by making fanc pluggable for backends we could "easily" add support to generate C#, JavaScript, C++, or other dynamic languages like PHP, Ruby, Python, etc.
brian Tue 28 Feb 2006
Here are the notes for the brainstorming Andy and I did over at his place tonight...
Things that really really suck regarding in-line native code integration:
So then I started thinking about our original ideas to make Fan a portable language for other "VMs" - namely targeting JavaScript which is the VM in all browsers - it could be as important as Java or .NET in the end. Plus for the embedded world there could still be big value in running C++ code.
So that leads to the out-of-line solution, which has the really crappy stub/merge problem. How do I partially implement a Fan class in Java or C#, but still get javac or csc to compile against the full signatures? More importantly it almost certainly means that I loose my clean single fcode deployable pod - if I'm going to do the out-of-line solution then I'm going to have to deal with deploying both a jar and dll in addition to my pod file.
So talking thru these all issues, leads us to solution where maybe we skip the whole back-end compile step entirely. Instead fanc generates Java, C#, or JavaScript source code. Let's take the graphics module example, with a directory structure as follows:
graphics +- fan | +- Shape.fan (pure Fan) | +- Graphics.fan (partially native) +- java | +- Graphics.java (partial class) | +- Utils.java (Java only support class) +- stage +- java-src | +- Shape.java (generated Shape.fan) | +- Graphics.java (merge Graphics.fan + Graphics.java) | +- Utils.java (pass-thru) +- java-lib +- Shape.class +- Graphics.class +- Utils.classThe first subdirectory fan contains the pure Fan code. Graphics.fan would stub some methods using the native keyword. Then the java subdirectory would contain the Java native code. Graphics.java would be a partial class - maybe use the partial keyword like C# introduced. This partial class would implement Fan native methods and add it's own Java specific methods and fields. I could also include whatever Java support classes I wanted (in a pod like sys, these classes might represent the bulk of the module).
In this design, fanc's job would be to emit not fcode, but rather Java source code (or C#, JavaScript, etc). Fanc would still do all the front end stuff like parsing, type checking, etc - but emit source code out a pluggable backend. It would also act as a build tool merging native source files with the emitted source files, copying the support files, sticking in a package declaration, etc. Lastly it would call out to javac to compile to classfiles setting up the classpath for jars of the dependent pods.
We would still need to generate something akin to a pod file which represents the pure Fan signatures for type checking (but probably not with fcode method implementations). Likely though this information would be embedded into the jar or .NET DLL since it is needed for reflection anyhow. Maybe we just always use jars for this purpose.
But by making fanc pluggable for backends we could "easily" add support to generate C#, JavaScript, C++, or other dynamic languages like PHP, Ruby, Python, etc.