[Haskell-cafe] Haskell on JVM
lgreg.meredith at biosimilarity.com
Wed Jun 24 19:32:39 EDT 2009
Simon, et al,
It might be interesting to look at
CAL<http://labs.businessobjects.com/cal/>as a non-blank-slate
beginning for Haskell on the JVM. To my mind there are
three things that this needs to make it a real winner:
- Much, much better Java interop. Basically, the bar to meet here is
- Better support for "std" Haskell syntax
- and better support for some of the basic (semantic and syntactic)
- Figuring out what of Hackage it is reasonable to support
Date: Tue, 23 Jun 2009 15:16:03 +0100
> From: Simon Peyton-Jones <simonpj at microsoft.com>
> Subject: RE: [Haskell-cafe] Haskell on the iPhone
> To: Rick R <rick.richardson at gmail.com>, Haskell Cafe
> <haskell-cafe at haskell.org>
> 638ABD0A29C8884A91BC5FB5C349B1C33F4BAAFA41 at EA-EXMSG-C334.europe.corp.microsoft.com
> Content-Type: text/plain; charset="us-ascii"
> Good news about the iPhone port!
> There seems to be quite a bit more interest now in supporting platforms
> other than win/*nix on x86 these days*. Maybe now there will be sufficient
> motivation to make the fundamental changes required. Caveat: I have
> absolutely no idea of the scope or complexity of said changes. I will look
> through the LambdaVM code (and iPwn when available) to get an idea.
> There is definitely an opportunity here for someone to make an impact.
> There is no reason in principle why Haskell can't run on a JVM or .net or
> other platform. But it's not just a simple matter of absorbing some patch
> or other. Here's a summary I wrote a little while ago:
> The short summary is:
> * There is interesting design work to do; and then interesting
> engineering work to make it a reality.
> * We (at GHC HQ) would love to see that happen, but are not likely
> to drive it.
> * If someone, or a small group, wanted to take up the cudgels and
> work on it, we'd be happy to advise.
> * We'd certainly consider folding the results into the HEAD,
> provided the author(s) are willing to maintain it, and we feel that the
> result is comprehensible and maintainable.
> * But another viable route might well be to use the GHC API, which
> means that the result wouldn't be part of GHC at all, just a client of the
> API. That would make it much easier to distribute upgrades etc, just as a
> Cabal package.
1219 NW 83rd St
Seattle, WA 98117
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe