Simon said:
GHC has a Java back end in development. You say ghc -J Foo.hs to produce
Foo.java.
Any particular reason for generating Java rather than JVM bytecode?
Does it make a difference?
Dr Ian Stark
Any particular reason for generating Java rather than JVM bytecode?
Does it make a difference?
Yes, we make *heavy* use of innerclasses and exceptions. So we are more than
happy to leave the dirty work to the Java compiler. (We are however
currently working on an "inner classes lifter" so that
GHC has a Java back end in development. You say ghc -J Foo.hs to produce
Foo.java.
It doesn't work properly yet (library and I/O issues mainly). But
Erik Meijer, Nigel Perry and Andy Gill are actively working on it.
So it'll work soon. Performance will not be great. More like Hugs than
GHC.
Johannes Waldmann:
Wouldn't it be nice if there were a Haskell compiler backend
that produced Java bytecode? Then I could write applets
in my favourite language, compile them, put them on my web page,
and everyone could execute them in their browser...
Seriously, is there any work in that
I would pose a different question: could you tell us *what kind
of applets* would you like to write in a pure lazy language, why
it would be more pleasant than Java (or Tcl/Tk, or ...)
What applets do I want? They should illustrate concepts
that we (*) teach in basic theoretical computer
Wed, 24 May 2000 01:24:57 -0700, Simon Peyton-Jones [EMAIL PROTECTED] pisze:
Performance will not be great. More like Hugs than GHC.
Is this because of lack of optimization, or is it inherent in using
Java bytecode?
--
__("Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
To those of you who are working on implementations:
How do you implement
1) tail recursion
2) polymorphism
3) closures eval (i.e., laziness)
Thanks,
--Thomas Johnsson
At 1:40 pm +0200 24/5/00, [EMAIL PROTECTED] wrote:
To those of you who are working on implementations:
How do you implement
Brief answers:
1) tail recursion
return to an evaluation loop (called "trampoline" by some?)
2) polymorphism
Object
3) closures eval (i.e., laziness)
Local
Marcin 'Qrczak' Kowalczyk wrote:
Wed, 24 May 2000 01:24:57 -0700, Simon Peyton-Jones [EMAIL PROTECTED] pisze:
Performance will not be great. More like Hugs than GHC.
Is this because of lack of optimization, or is it inherent in using
Java bytecode?
I guess the poor performance
[EMAIL PROTECTED] wrote:
To those of you who are working on implementations:
How do you implement
1) tail recursion
2) polymorphism
3) closures eval (i.e., laziness)
One approach worth mentioning is described in
David Wakeling: "Compiling lazy functional programs for the Java Virtual
Hi Thomas,
Some quick answers in addition to Nigel's
1) tail recursion
We use the usual "trampoline" trick, with a little top-level interpretative
loop. Using the trick has a pleasant side effect that we can pass values on
the arguments stack as well.
2) polymorphism
All type informations
For MLj the answers so far as I remember are:
[EMAIL PROTECTED] wrote:
To those of you who are working on implementations:
How do you implement
1) tail recursion
You can only do so much. The Java VM has a goto instruction but you
can't jump from one virtual method to another. Things
At 2:07 pm +0200 24/5/00, Artur Zawlocki wrote:
Marcin 'Qrczak' Kowalczyk wrote:
Wed, 24 May 2000 01:24:57 -0700, Simon Peyton-Jones
[EMAIL PROTECTED] pisze:
Performance will not be great. More like Hugs than GHC.
Is this because of lack of optimization, or is it inherent in using
13 matches
Mail list logo
