ghc-4.00
Still can't build 4.00 from source (see bug report, elselist), and it's also not yet on the ftp site in binary form. *whinge!* Slainte, Alex.
rename class Functor ?
Simon Peyton-Jones [EMAIL PROTECTED] writes We're nearly done with Haskell 98. ... In the Prelude ~~~ class Functor f where fmap :: (a - b) - f a - f b What about renaming it, say, to Mappable f ? It looks like the word `functor' is taken from the very category theory and restricted in the recent Haskell to the subcategories of Set. Some categories have the morphisms not of kind a - b (mapping from a to b), and their functors occur not functors according to recent Haskell. Example. The category of the subsets of alphabet with the morphisms from s1 to s2 being the words that begin with the letter from s1 and terminate with the letter from s2 - or, i guess, people can invent the right examples. -- Sergey Mechveliani [EMAIL PROTECTED]
Re: rename class Functor ?
At 09:13 +0300 1998/11/16, S.D.Mechveliani wrote: In the Prelude ~~~ class Functor f where fmap :: (a - b) - f a - f b What about renaming it, say, to Mappable f ? It looks like the word `functor' is taken from the very category theory and restricted in the recent Haskell to the subcategories of Set. To begin with, one should not confuse the "category" Haskell provides with the category of Sets. Then, I do not think that Haskell aims at providing all possible categories: It is simply named functor because that is the mathematical inspiration. So, within those interpretations, it is a functor, but not a description of all functors, or even a functor in the strict mathematical sense. Then this name is acceptable to me, because that is the state of the art of programming. But if you have a better way to implement more general categories in Haskell, then I think that one might need changing the name as you propose. Hans Aberg * Email: Hans Aberg mailto:[EMAIL PROTECTED] * Home Page: http://www.matematik.su.se/~haberg/ * AMS member listing: http://www.ams.org/cml/
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
