>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.
It was a frustrating experience, and I spend a lot of time debugging
perfectly correct programs, searching for documentation, and waiting for
operating system upgrades and patches to be installed so that I could
test with newer betas and fresh bugs. That's why my postings were so
negative.
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.
>I browsed through the Opal docs and could not find the relevant
>documentation on a Java interface. Can you provide a more specific URL?
I've got a printout of a section of the Bibliotheca Opalica
documentation
http://uebb.cs.tu-berlin.de/~opal/ocs/doc/html/index.html
from November 6th in which a Subsystem Java appears in Subsystem Tools,
right after Subsystem Tk. I couldn't find any other reference then, and
even this bit of documentation seems to have vanished from their web
pages now..
>I would love to alpha test your Hakell2Java code.
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.
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.
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.
Usually, coercions loose information, but as long as I don't try to keep
copies of Java objects in Haskell land, I do not loose `real'
information. Only my Haskell-side view of a Java-side object gets
incomplete when I coerce, e.g., a ColourPoint view into a Point view. If
I want to recover the more complete view by coercing a Point view into a
ColourPoint view, this is a partial operation that has to be guarded by
a check (is this Point really an instance of ColourPoint, too?).
Claus
