Re: Calling Java From Haskell
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
Re: Calling Java From Haskell
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 voice1-212-697-1427 fax
Re: Calling Java From Haskell
Hello! Only a few comments to your mappings. On Fri, Nov 13, 1998 at 10:02:02AM -0500, S. Alexander Jacobson wrote: [...] Java Haskell --- --- Class Module Static method function And IO tagged result, as the method may be impure. Instance Module.Instance (Haskell data type) Instance Method (Module.Instance -) (function w/ instance arg) And IO tagged result, as the method may be impure. get static variable function w/ no args In fact: get_varName :: IO value_type, as the value can change set static variable set_varName::value-IO () get instance variable varName::Instance-value varName :: Instance - IO value, as the value can change, again. set instance variable set_varName::Instance-value-IO() Regards, Felix.
Re: Calling Java From Haskell
My interpretation of the last set of mailings on the issue was that people had given up. Obviously that was incorrect. I would love to alpha test your Hakell2Java code. I browsed through the Opal docs and could not find the relevant documentation on a Java interface. Can you provide a more specific URL? -Alex- On Fri, 13 Nov 1998, Claus Reinke wrote: Now that Javasoft is on the verge of releasing the jdk1.2, I figure that it is time to try to call Java from Haskell again. fine. do it. Alternatively, you might scan your mailbox for related messages and find one - addressed to you and to the Haskell list. Or you might check the home page of that particular author and find a recent paper (IFL'98, September, London) that discusses some of the issues and points to some related work and documentation. And since there is still no link to my Haskell/JNI pages from my home page, you might even ask me why I don't seem to make any progress.. In that earlier posting, I mentioned that I intended to use Green Card and JNI and that I wanted to have a basis for further experiments before this year is over. The background and my design decisions are explained in the IFL paper and I haven't announced any software because I don't think it is ready yet (even if it was, it depends on software that hasn't been released yet). And before others swamp me with personal email now;-), here are some comments on the state of the art: - While it is reasonably easy to use the invocation API in Java's native interface (JNI) from C, I didn't have much luck in trying to get JDKs in the 1.x range to cooperate with Hugs on my SUN SPARCstation. My best bet are interactions with the user-level thread packages used in those JDK implementations (or, as SUN's JNI FAQ used to put it: ``The Solaris Java VM shipped with JDK 1.1 is not suitable for embedding into certain native applications. Because it depends on a user-level thread package to implement Java threads, the VM overrides a number of system calls in order to support non-blocking I/O. This may have undesirable affects on the hosting native application.''). - JDK1.2 betas have been available for some time now, so there is no need to wait for the official release to develop something. Of course, betas have bugs - e.g., JDK1.2beta3 had serious problems with its invocation API, betas change, so you have to track the changes, and betas might not have complete documentation. - Nevertheless, I've been testing successfully with JDK1.2beta4 and JDK1.2 RC1 (release candidate 1), using Hugs1.4June1998 and Green Card. Example programs run both on a SPARCstation with Solaris 2.6 (with the suitable linker patches) and on a PC with Windows/NT. - My tentative conclusion is that I'll probably be able to release a beta version of Haskell/JNI by the end of this month (which is also the expected release date for JDK1.2 proper). I'll be looking for alpha-testers before that, but there are still some things I would like to check/change before I release anything.. - As I said before: If anyone else is working on this, please let me know. Also, if you desperately want to be an alpha-tester, please contact me directly. In other words: watch this space!-) Claus PS. I've been planning to investigate the generation of Haskell modules from Java classes to hide calls to Haskell/JNI even before I got caught in ``implementation details'', although not along the lines of your suggested mapping. The OPAL group in Berlin seems to have such a thing already (http://uebb.cs.tu-berlin.de/~opal/, look for the Subsystem Java in their library documentation). -- Claus ReinkeDepartment of Computer Science email: [EMAIL PROTECTED]University of Nottingham http://www.cs.nott.ac.uk/~czr/ Nottingham NG7 2RD ___ S. Alexander Jacobson i2x Media 1-212-697-0184 voice1-212-697-1427 fax
Re: Calling Java From Haskell
I would like to point out that on Solaris there are 2 SUN JDK releases: so-called reference (put out by Javasoft) and production (by SunSoft). The latter has had native threads for a while. Certainly they are here in 1.6 and 1.7. I don't know what is the situation on Windows, though. -- O.L.
