Re^3: Interaction between languages in Parrot

Being more optimistic, will it be possible to subclass a Java class in Perl6 and then use it as a method argument to another Java class?

My sticking point is subclassing back to Java. A somewhat contrived example:

In Perl 6:

class MyPerlClass
    method foo {...};
    method bar {...};
[download]

...then to extend the class in Java

class MyJavaClass extends MyPerlClass {
    public void output() {System.out.println(foo() + bar());}
}
[download]

Add or concatonate?

The programmer still needs additional interfacing definitions, or castings or something. It doesn't look seamless.

Comment on Re^3: Interaction between languages in Parrot Select or Download Code

Replies are listed 'Best First'.
Re^4: Interaction between languages in Parrot by stvn (Monsignor) on Dec 23, 2005 at 04:21 UTC
Well the Perl would compile into something like this (I wrote this in PIR instead of PASM because I am not that much of a masocist :) `.namespace [ "MyPerlClass" ] .sub "__onload" :load .local pmc klass newclass klass, "MyPerlClass" .return () .end .sub foo $S0 = "MyPerlClass::foo" .return($S0) .end .sub bar $S0 = "MyPerlClass::bar" .return($S0) .end` [download] And the Java would compile into something like this: .namespace [ "MyJavaClass" ] .sub "__onload" :load .local pmc klass $P0 = getclass "MyPerlClass" # load the Perl class subclass klass, $P0, "MyJavaClass" .return () .end .sub output .local pmc System .local pmc String $S0 = self.foo() $S1 = self.bar() concat $S2, $S0, $S1 # assume that the Java # standard libraries exist System = getclass "java.lang.System" String = getclass "java.lang.String" # assume that a String object can be # constructed from a native Parrot string $P0 = String.new($S2) $P1 = System.out() $P1.println($P0) .return () .end [download] Of course I am simpliying here, Java classes would need to inherit from java.lang.Object somehow, so maybe the Java compiler writer would have a special PMC specifically for Java classes (although compatible with normal PMC classes too). As for how we know that the return values of `self.foo()` and `self.bar()` are Parrot strings and not java.lang.String. It is not outside the range of the compiler's abilities to determine this, especially since it would be known that foo and bar are not defined in MyJavaClass, and could (maybe) be assumed to be coming from MyPerlClass. Of course it does get trickier if either of those methods actually came from MyPythonClass which maybe MyPerlClass would inherit from (not shown in the example). But what I am trying to get at really is that once everything is compiled to PIR/PASM, it really doesn't make much difference. Most of the problems you are bringing up are problems that the compiler writers will have, and should not be problems that users are made to deal with. If users have to deal with these issues, then the compiler is not doing it's job correctly. UPDATE: I forgot to address your last question :) Add or concatonate? The programmer still needs additional interfacing definitions, or castings or something. It doesn't look seamless. Does the programmer need to deal with this in regular (non Parrot) Java? Of course not `javac` handles it. Why would a Java to Parrot compiler be any different? Given enough static anaylsis, this is a likely a fairly trivial case. -stvn	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^4: Interaction between languages in Parrot
by stvn (Monsignor) on Dec 23, 2005 at 04:21 UTC

Well the Perl would compile into something like this (I wrote this in PIR instead of PASM because I am not that much of a masocist :)

.namespace [ "MyPerlClass" ]

.sub "__onload" :load
    .local pmc klass
    newclass klass, "MyPerlClass"
    .return ()
.end

.sub foo 
    $S0 = "MyPerlClass::foo"
    .return($S0)
.end

.sub bar 
    $S0 = "MyPerlClass::bar"
    .return($S0)
.end
[download]

.namespace [ "MyJavaClass" ]

.sub "__onload" :load
    .local pmc klass
    $P0 = getclass "MyPerlClass"  # load the Perl class 
    subclass klass, $P0, "MyJavaClass"
    .return ()
.end

.sub output 
    .local pmc System
    .local pmc String
    $S0 = self.foo()
    $S1 = self.bar()
    concat $S2, $S0, $S1    
    # assume that the Java 
    # standard libraries exist 
    System = getclass "java.lang.System"
    String = getclass "java.lang.String"
    # assume that a String object can be
    # constructed from a native Parrot string 
    $P0 = String.new($S2)  
    $P1 = System.out()
    $P1.println($P0)
    .return ()
.end
[download]

self.foo()

self.bar()

But what I am trying to get at really is that once everything is compiled to PIR/PASM, it really doesn't make much difference. Most of the problems you are bringing up are problems that the compiler writers will have, and should not be problems that users are made to deal with. If users have to deal with these issues, then the compiler is not doing it's job correctly.

UPDATE:
I forgot to address your last question :)

Add or concatonate? The programmer still needs additional interfacing definitions, or castings or something. It doesn't look seamless.

Does the programmer need to deal with this in regular (non Parrot) Java? Of course not javac handles it. Why would a Java to Parrot compiler be any different? Given enough static anaylsis, this is a likely a fairly trivial case.

-stvn

[reply]
[d/l]
[select]