new language extensions

[Duncan Coutts]

In message <20080106175119.GB16859 at momenergy.repetae.net> Haskell Libraries
<libraries at haskell.org>, Duncan Coutts <duncan.coutts at worc.ox.ac.uk> writes:
> On Thu, Nov 08, 2007 at 02:27:55PM +0000, Ian Lynagh wrote:
> > On Wed, Nov 07, 2007 at 09:40:25PM +0000, Duncan Coutts wrote:
> > > Last call for objections or comments.
> > > 
> > > We'd like to get this into Language.Haskell.Extension asap so we can
> > > include it in the Cabal distributed with ghc-6.8.2. Currently there are
> > > packages that compiled fine with Cabal and ghc-6.6.x but not with
> > > ghc-6.8.x because we're missing these new more fine-grained language
> > > extensions.
> > > 
> > > See http://hackage.haskell.org/trac/hackage/ticket/160
> > 
> > I'd much rather see http://hackage.haskell.org/trac/hackage/ticket/147
> > fixed. Then Cabal would work with future GHCs, with new extensions as
> > yet undreamt of, as well.
> 
> Yes, I would like to see this too, I have not really done a lot of work
> integrating jhc with cabal, but this 'baked in' extension type was
> something of an issue.

How so? It's easy to extend it, just send us a patch with the extras.

> (jhc itself understands a subset of the cabal
> file type and can build libraries based on them with jhc --build-hl).

Honestly, I'd prefer to see better support in Cabal for jhc than have each
Haskell implementation do a half-complete .cabal file processor. nhc98 has been
doing this too and it'll only ever half work. As a Cabal patch reviewer I'm very
happy to see patches to improve support for nhc98, jhc etc, and if the code is
in Cabal then we can stop it from suffering bit rot so quickly.

> There are a couple other places where a 'newtype String' made more sense
> too if I recall.

I don't mind so much if it's a string or an enum, but keeping a central register
seems like a good thing to me and an enum enforces that. We could certainly make
the parsing a bit more sensible so it doesn't fall over when it encounters an
unknown extension.

> Perhaps just a simple wiki page where we can "register" extension names
> is in order as there are a few jhc understands that arn't in the cabal
> extension type (nor should they be if this fix is completed). 

Or using the existing mechanism, you can darcs send a patch to
Language.Haskell.Extension to "register" your extension names. I fail to see how
a wiki page is better.

Duncan