Simon, et al,<br><br>It might be interesting to look at <a href="http://labs.businessobjects.com/cal/">CAL</a> 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:<br>
<ul><li>Much, much better Java interop. Basically, the bar to meet here is Scala/Java interop.</li><li>Better support for "std" Haskell syntax</li><ul><li>and better support for some of the basic (semantic and syntactic) extensions<br>
</li></ul><li>Figuring out what of Hackage it is reasonable to support<br></li></ul><br>Best wishes,<br><br>--greg<br><br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">
Date: Tue, 23 Jun 2009 15:16:03 +0100<br>
From: <span class="il">Simon</span> <span class="il">Peyton</span>-<span class="il">Jones</span> <<a href="mailto:simonpj@microsoft.com">simonpj@microsoft.com</a>><br>
Subject: RE: [Haskell-cafe] Haskell on the <span class="il">iPhone</span><br>
To: Rick R <<a href="mailto:rick.richardson@gmail.com">rick.richardson@gmail.com</a>>, Haskell Cafe<br>
<<a href="mailto:haskell-cafe@haskell.org">haskell-cafe@haskell.org</a>><br>
Message-ID:<br>
<<a href="mailto:638ABD0A29C8884A91BC5FB5C349B1C33F4BAAFA41@EA-EXMSG-C334.europe.corp.microsoft.com">638ABD0A29C8884A91BC5FB5C349B1C33F4BAAFA41@EA-EXMSG-C334.europe.corp.microsoft.com</a>><br><br>
Content-Type: text/plain; charset="us-ascii"<br><br>
Good news about the <span class="il">iPhone</span> port!<br><br>
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.<br><br>
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:<br><a href="http://haskell.org/haskellwiki/GHC:FAQ#Why_isn.27t_GHC_available_for_.NET_or_on_the_JVM.3F" target="_blank">http://haskell.org/haskellwiki/GHC:FAQ#Why_isn.27t_GHC_available_for_.NET_or_on_the_JVM.3F</a><br>
<br>
The short summary is:<br><br>
* There is interesting design work to do; and then interesting engineering work to make it a reality.<br><br>
* We (at GHC HQ) would love to see that happen, but are not likely to drive it.<br><br>
* If someone, or a small group, wanted to take up the cudgels and work on it, we'd be happy to advise.<br><br>
* 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.<br><br>
* 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.<br><br><span class="il">Simon</span><br clear="all"></blockquote>
<br>-- <br>L.G. Meredith<br>Managing Partner<br>Biosimilarity LLC<br>1219 NW 83rd St <br>Seattle, WA 98117<br><br>+1 206.650.3740<br><br><a href="http://biosimilarity.blogspot.com">http://biosimilarity.blogspot.com</a><br>