<br><br><div class="gmail_quote">On Wed, Apr 23, 2008 at 3:40 PM, Adrian Hey <<a href="mailto:ahey@iee.org">ahey@iee.org</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">Thomas van Noort wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
As you already noticed, there is no Windows binary available for the Emerald release. However, there is one for the Coral release, available from:<br>
<br>
<a href="http://www.generic-haskell.org" target="_blank">http://www.generic-haskell.org</a><br>
<br>
Although this is an old release of Generic Haskell, this release already supports generic types, which is what you need for your project probably. In the user's guide, there is a small example available which defines a generic type to represent tries.<br>
</blockquote>
<br></div>
Thanks, but this won't register itself as a package with current ghc,<br>
and even I fixed that problem I guess it probably still wouldn't<br>
work :-(<br>
<br>
It's entirely up to you folks of course. I don't know if anyone at GHHQ<br>
cares enought to do anything about the buildability problem. But if not<br>
I'm afraid I can't see this being used or accepted as part of standard<br>
Haskell infrastructure. It'll just be something people look at, admire<br>
the coolness, maybe even tinker with for a while, but never really use<br>
for anything serious.</blockquote><div><br>I don't see GH moving away from Makefiles in the future. First, we need to track dependencies on AG and GH source files, which would require a fair amount of effort to implement in a Cabal-based build. Second, GH installs with no problems on the platforms we use (Linux and Mac OS X systems). As an aside, note that there are other Haskell projects that do not have Cabal based builds such as GHC and Gtk2hs.<br>
<br>GH previously supported cygwin-based builds but it is broken due to some cygwin changes. At the moment we do not plan to fix it, but if there is enough interest we could be persuaded to do so. However, if you really need a Cabal-based build without Cygwin or MSYS dependencies, then I guess you are out of luck :).<br>
<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
Meanwhile I think the GSoC project I mentioned will have to make other<br>
arrangements :-)<br>
<br>
To be honest though, I'm not sure we'd use it anyway as I understand<br>
it generates essentially pure H98 and there are ghc extensions we'd<br>
probably want to use for performance reasons (like unboxed Ints and<br>
unboxed tuples).</blockquote><div><br>You can always use a generated H98 module with a non-H98 module. However, if your generic function uses non-H98 features, it could get tricky. There are solutions for that, though.<br>
<br>Cheers,<br><br>Alexey<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
Regards<br>
--<br><font color="#888888">
Adrian Hey</font><div><div></div><div class="Wj3C7c"><br>
<br>
<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org" target="_blank">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
</div></div></blockquote></div><br>