Re: Calling Java From Haskell

[S. Alexander Jacobson]

On Mon, 16 Nov 1998, Claus Reinke wrote:
> >My interpretation of the last set of mailings on the issue was that people
> >had given up.  Obviously that was incorrect.
> 
> We never give up!-) Well, almost never.

:-)
 
> Finally, I had to put the problem aside and wait for the environment
> (JDK implementation + our local OS installation) to match the
> specifications, and it wasn't until last month that I was able to make
> real progress on the implementation side. 

That was the idea behind my post, but I guess you are way ahead of me.
 
> Great! I guess I can send you the Haskell/JNI stuff next Monday, so that
> you can experiment with your Java->Haskell mapping on top of that. 

I assume that means next week.  Cool!
 
> As Felix pointed out, contacts with the Java world should live in the IO
> monad. Also, you cannot link to Java byte code statically, so your
> Haskell modules would probably need some init_module entrypoint (which
> loads the Java class and finds pointers to its methods). And if you
> don't want to do the initialization again for each call to Java, the
> idea of static Haskell function <-> static Java method breaks down, too.

The init_module can be hidden in the generated Haskell/Java modules.
Calls to java functions can be prefaced by a check to some global static
variable.
If the static variable is null then Java is initialized, otherwise
the initialized VM is used.
 
> Your mapping suggests that the extends relation in Java could correspond
> to an import/(re-)export relation in Haskell. While this might be
> helpful for structuring the programs (in the form package<->module?), it
> doesn't solve the subclassing <-> subtyping issue. For instance, can I
> pass a ColourPoint.instance to a (Point.instance -> distanceFrom
> Point.instance) that expects a Point.instance in your mapping? The
> mysteriously disappearing Opal document mentioned explicit coercions
> along the class hierarchy for this purpose.

Why can't we we use typeclasses to represent java class interfaces (as
well as java interfaces) and declare java classes to be instances
of the corresponding haskell type classes?  So a function that takes a
vector as an argument would be represented as:

> vecLength::(Vector v)=>v->IO Int

Then if we had another class that extends Vector, it would have some
declaration like:

> instance Vector MyVector where
> ....

and so they can't do this.

-Alex-

___________________________________________________________________
S. Alexander Jacobson                   i2x Media  
1-212-697-0184 voice                    1-212-697-1427 fax