Is supporting both CLR and JVM feasible?

[Charles]

I have kicked off a wiki page that summarizes the differences between CLR and JVM and to a lesser extent, some differences with C# and Java: DifferencesBetweenClrAndJvm.

Feel free to augment it with additional bullet points or additional sections.

I know that many differences between the two can be smoothed out. I've thought about the issues before to some degree as I initiated the JVM back-end. But I'm wondering if all the differences can be smoothed out? This question is mostly addressed to Hops, who has been doing all the JVM work for quite awhile.

Here are some specifics:

-- How will Cobra's unsigned integer types work on JVM?

-- How will this work on JVM?

class A

    def foo(t as List<of int>)
        pass

    def foo(t as List<of String>)
        pass

-- Can generics really be formulated in such a way that they work on both systems?

-- How will partial classes be handled on the JVM?

-- How about other CLR oriented features like "out" and "ref", value types, explicit interface implementations and so on?

Is this really possible?

Also, I'd like to point out an idea I floated a long time ago of having 3 Cobra dialects: Portable, .NET and JVM. I guess my post here is asking if the "Portable" dialect is really possible?

[hopscc]

Can all the differences be smoothed out?

Dont know yet. So far so good

Specifics:

How will Cobra's unsigned integer types work on JVM?

As handle unsigned int types in java, widen to the next biggest type and mask ( if necessary)
( I'm hoping Java comes to its senses and eventually supports unsigned types natively - theres supporting util methods in guava that can be mined or leveraged to assist with this)

-- How will this work on JVM? - aliased fncalls via generics and Type erasure

Dont know - havent thought about this as its wrt generics and I've not started on that area massively yet
Can you implement the equivalent of this in Java or does the java compiler whine about it?

Can generics really be formulated in such a way that they work on both systems?

Dunno for sure - some (small) level of generic support is working now (surprisingly) and nothing I've tried against it so far has actually failed impossibly. OTOH I've not tried anything against generics very hard or worked up to the generics test cases.
Some of the details around constraints may need revisiting
If/When get to exercising against that area I'll have more of a definitive answer.

How will partial classes be handled on the JVM?

The cobra compiler (codegen) will detect + hold the partial pieces and aggregate them into a single complete class that is then emitted for java compile ( I thought cobra was just relying on C# compiler for all this but I vaguely recall last time I skimmed over that portion of code I thought the cobra compiler was already doing some elements of that)

How about other CLR oriented features like "out" and "ref",

If we even bother supporting this ( rather than putting effort into multiple return values instead)
cobra turn these keywords into emitted java code providing call-by-ref semantics
(inserted boiler plate in call preamble that declares wrapping objects, inserts the call-by-ref arg into them, passes wrapped object to fn, unwraps same in called fn preamble, extracts call-by-ref arg in call postamble).

value types,

At this point I've not thought much about all the ramifications of these.
Some level of this is just not fully supportable ( so structs in cobra are still just classes in java).
There seems no issues with inbuilt valuetypes (primitives) to date but I'm not sure if thats due autoboxing smoothing these out or just havent hit the tar-pit cases yet.
OTOH these are 'just' for performance optimisation so not supporting these directly in java is possibly 'just' a possible performance sink.

explicit interface implementations

Dont know what you mean here - pls expand

and so on?

and so forth.

Is this (portable dialect) really possible?

Lets put it this way - nothing I've seen so far indicates that it is impossible and I thought I would have hit some strong indication of that to date. I'm working on the assumption ( so far not disproved) that if anything in C# that cobra uses not in Java can be implemented (somehow) in java I can make the cobra compiler (codegen) emit the right stuff to make it happen.
(Wait till we start hitting on support for delegates/signatures - its doable but it wont be pretty)

I expect the most problematic area will be around generics ( and issues from Type erasure) but I also expected to get smacked by that before now so at this stage I'm still hopeful.

I had thought that inline lambdas and anon methods would be a no go area but java8 is supposed to provided something there we can
leverage off so I'm less concerned about that now.
Fortunately at this point we are not welded to any base java platform and it is a (very slowly evolving ) choosable target to aim for.

Worst case is that some ( hopefully small) supported areas of cobra are just not possible to do or
not possible to do the same way converting to java from sensible idiomatic cobra code
- so you have to write different cobra code than for .Net for the same thing.

This is why I think cobra language needs the equivalent of platform ifdef blocks ( @platform(jvm), @platform(clr)) for platform varying code ( which we need anyway for the differences in libraries).
Also we are not precluded from changing (fixing) cobra to push these details away from a platform implementation ( like for Enums and set inclusion bitops)

Please dont forget that this is the first-port to a different platform and thats the one where you find your initial implementation was perhaps overly 'first-platform' specific.

The multiple dialect possibility is a worst case fallback - we can support non CLR platforms but its with a subset or non compatible variant...
I dont see this as particularly useful unless the non varying pieces are immeasurably superior to the native platform+language ( not a high hurdle for any of them ) and there are no superior alternatives on that platform (oops ).

Total and utter failures in the above arent cause for abandonment anyway.
I/we are currently targeting simplest and lowest level case - java/jvm.
The current crop of new jvm languages ( ceylon, kotlin) are a much better semantic and capability fit in many cases ( better generics at least) than java and would be as relatively easy to target for back end purposes...

Hmmm...
What are the core features of cobra that if we dont support on other platforms make it 'non-cobra' on those platforms ???
How much variance/difference across back end platforms is acceptable ?

[hopscc]

re overloaded fn calls with type erased generic parameters
- Do as you'd do in writing java code by hand

(automatically) rename the methods ( name mangling)

class A

    def foo(t as List<of int>)
        pass

    def foo(t as List<of String>)
        pass

emits java code as if it was written as

class A

    def fooListi(t as List<of Integer>)
        pass


    def fooListS(t as List<of String>)
        pass

( the suffixes are approximate JNI coding for the Types used)

another alternative is to detect this situation when generating for the java BE and tell them 'you cant do that'
or just generally - 'not enough parameter and name differences in overloaded methods - rename one of these methods'