[Haskell-cafe] Re: [Haskell] ANNOUNCE: Generic Haskell 1.80 (Emerald)

[Alexey Rodriguez]

On Wed, Apr 23, 2008 at 3:40 PM, Adrian Hey <ahey at iee.org> wrote:

> Thomas van Noort wrote:
>
> > As you already noticed, there is no Windows binary available for the
> > Emerald release. However, there is one for the Coral release, available
> > from:
> >
> > http://www.generic-haskell.org
> >
> > 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.
> >
>
> Thanks, but this won't register itself as a package with current ghc,
> and even I fixed that problem I guess it probably still wouldn't
> work :-(
>
> It's entirely up to you folks of course. I don't know if anyone at GHHQ
> cares enought to do anything about the buildability problem. But if not
> I'm afraid I can't see this being used or accepted as part of standard
> Haskell infrastructure. It'll just be something people look at, admire
> the coolness, maybe even tinker with for a while, but never really use
> for anything serious.


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.

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 :).



>
>
> Meanwhile I think the GSoC project I mentioned will have to make other
> arrangements :-)
>
> To be honest though, I'm not sure we'd use it anyway as I understand
> it generates essentially pure H98 and there are ghc extensions we'd
> probably want to use for performance reasons (like unboxed Ints and
> unboxed tuples).


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.

Cheers,

Alexey


>
>
> Regards
> --
> Adrian Hey
>
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080423/0a996cac/attachment.htm