In my experience, there's just a huge mismatch between the execution
models. (As for "experience": in addition to studying the JVM quite a
lot, I also had a one-semester course at the university as part of my
grad studies on implementing a VM for a subset of Haskell. 'twas a
very interesting course, even given that we had to emulate the machine
on paper for our exam... Funny thing was, the same VM with very slight
modifications could then also be used to run Prolog programs. I also
examined the Glasgow Haskell Compiler innards for a while. Anyway, I
don't claim any of these make me an expert in Haskell implementations,
but I'm aware of hurdles.)
Basically, the strict laziness of Haskell is not possible to
seamlessly marry with JVM's stack based call-and-return execution
model (at least I'm not smart enough to see how). Necessary tricks
with continuation-like constructs ("interface Code { Code exec() }")
all make the implementations very involved and hard to maintain, and
proliferation of heap-allocated thunks doesn't help performance either.
Writing an interpreter for Haskell would be no big deal, but it has
the performance you'd expect. Writing an efficient compiler, either to
bytecode or native machine code is an entirely different matter. If
you take a look at how Glasgow Haskell Compiler implements all of
this, you'll see that it emits C code that does *not* actually work as
expected with regard to strict lazy evaluation, runs it through a C
compiler, then after the C compilation step it will transform the
compiled object code, mostly putting jump sites in places of function
returns and finally link the doctored object code into an executable.
Now, you can do that with unmanaged machine code. Clearly, you can't
do that with the managed runtime environment of the JVM. (Nor with
CLR, for that matter. Given how both Erik Meijer and Simon Peyton-
Jones are Microsoft employees, if it were possible, I have no doubts
they would have since made it happen.) And the MLVM innovations don't
point in these directions either - well, continuations or at least
generators could help, I think.
Again, I don't claim these problems are unsurmountable, I'm just
saying I don't see how to solve them in a manner that is both
efficient and elegant. I'd be delighted to see someone smarter than me
overcome these problems for having an *efficient* Haskell on the JVM
implemented *elegantly*. That'd really rock.
Attila.
On 2009.06.30., at 1:40, Tom Davies wrote:
>
>
>
> On Jun 26, 6:53 am, Attila Szegedi <[email protected]> wrote:
>> Good luck with that. All previous attempts run into very ugly
>> problems
>> in implementing lazy evaluation (and no, tail calls won't solve
>> that).
>
> What are the ugly problems here? I've used CAL (sort of Haskell 98 for
> the JVM minus some syntactic sugar) happily, although certainly you
> can get big performance improvements by indicating strictness.
>
> Tom
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "JVM
Languages" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/jvm-languages?hl=en
-~----------~----~----~----~------~----~------~--~---
