new language extensions

newer
[Fwd: Re: Maps, was Re: GHC source...

Duncan Coutts

5 Nov 2007 5 Nov '07

5 p.m.

All, GHC 6.8 has a lot of new names for language extensions which are not yet listed in Language.Haskell.Extension: UnicodeSyntax PatternSignatures UnliftedFFITypes LiberalTypeSynonyms TypeOperators PArr RecordWildCards RecordPuns DisambiguateRecordFields OverloadedStrings GADTs MonoPatBinds RelaxedPolyRec ExtendedDefaultRules UnboxedTuples DeriveDataTypeable ConstrainedClassMethods These are the extension names you can list in the "extensions:" field in a .cabal file and are also in the {-# LANGUAGE #-} pragma. So I propose we add all of these to the Extension enumeration data type. I'd like to keep this addition separate from the proposal to make Extension a String or newtype String, since I expect even in that case we need a central list of extensions so different implementations can agree on names when they implement the same extensions, or to ensure they pick different names for different extensions. It'd also be nice if we could document all these extensions in the Language.Haskell.Extension module so we can refer to it from the cabal documentation about the extensions field. Duncan

Show replies by date

Manuel M T Chakravarty

5 Nov 5 Nov

5:51 p.m.

Duncan Coutts wrote:

...

GHC 6.8 has a lot of new names for language extensions which are not yet listed in Language.Haskell.Extension: [..] PArr [..] So I propose we add all of these to the Extension enumeration data type.

I am sure we still want to change this one (maybe into ParallelArrays). The feature isn't ready for prime time yet, which is why nobody has been paying attention to flag names. Anyway, this is just to say, please don't bake this in yet. Manuel

Duncan Coutts

6:43 p.m.

On Tue, 2007-11-06 at 09:51 +1100, Manuel M T Chakravarty wrote:

...

Duncan Coutts wrote:

...
GHC 6.8 has a lot of new names for language extensions which are not yet listed in Language.Haskell.Extension: [..] PArr [..] So I propose we add all of these to the Extension enumeration data type.

I am sure we still want to change this one (maybe into ParallelArrays). The feature isn't ready for prime time yet, which is why nobody has been paying attention to flag names.

Anyway, this is just to say, please don't bake this in yet.

Ok, we can leave that one out for now. Duncan

Duncan Coutts

7 Nov 7 Nov

4:40 p.m.

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 Duncan On Mon, 2007-11-05 at 22:00 +0000, Duncan Coutts wrote:

...

All,

GHC 6.8 has a lot of new names for language extensions which are not yet listed in Language.Haskell.Extension:

UnicodeSyntax PatternSignatures UnliftedFFITypes LiberalTypeSynonyms TypeOperators PArr RecordWildCards RecordPuns DisambiguateRecordFields OverloadedStrings GADTs MonoPatBinds RelaxedPolyRec ExtendedDefaultRules UnboxedTuples DeriveDataTypeable ConstrainedClassMethods

These are the extension names you can list in the "extensions:" field in a .cabal file and are also in the {-# LANGUAGE #-} pragma.

So I propose we add all of these to the Extension enumeration data type.

I'd like to keep this addition separate from the proposal to make Extension a String or newtype String, since I expect even in that case we need a central list of extensions so different implementations can agree on names when they implement the same extensions, or to ensure they pick different names for different extensions.

It'd also be nice if we could document all these extensions in the Language.Haskell.Extension module so we can refer to it from the cabal documentation about the extensions field.

Duncan _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Malcolm Wallace

8 Nov 8 Nov

7:29 a.m.

Duncan Coutts wrote:

...

Last call for objections or comments.

Is there a definitive (maybe even formal?) description of the change to the language embodied by each of these extensions? If not, then it is going to be difficult for implementations other than ghc to implement them.

...

...
UnicodeSyntax PatternSignatures UnliftedFFITypes LiberalTypeSynonyms TypeOperators PArr RecordWildCards RecordPuns DisambiguateRecordFields OverloadedStrings GADTs MonoPatBinds RelaxedPolyRec ExtendedDefaultRules UnboxedTuples DeriveDataTypeable ConstrainedClassMethods

Regards, Malcolm

Duncan Coutts

8:31 a.m.

On Thu, 2007-11-08 at 12:29 +0000, Malcolm Wallace wrote:

...

Duncan Coutts wrote:

...
Last call for objections or comments.

Is there a definitive (maybe even formal?) description of the change to the language embodied by each of these extensions? If not, then it is going to be difficult for implementations other than ghc to implement them.

Most, but not all are documented in the GHC users guide. It would not be unreasonable to ask for a proper description of the remaining ones. http://haskell.org/ghc/docs/latest/html/users_guide/ghc-language-features.ht... Unfortunately the user guide does not make it entirely clear what language extension name to use in each case. http://www.haskell.org/ghc/docs/latest/html/users_guide/flag-reference.html#... Personally I would quite like to include documentation and a little example for each one in the Language.Haskell.Extension haddock docs. That would be a useful reference for users trying to figure out which extension it is they need to enable. Duncan

Ian Lynagh

9:27 a.m.

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. This would provide the mechanism we need; the policy, i.e. what the extension names mean, should be defined somewhere outside of Cabal. (you would still need to add the new extension names defined in 6.8.1 to the legacy mapping for 6.6 flags). Thanks Ian

Duncan Coutts

5:42 p.m.

On Thu, 2007-11-08 at 14:27 +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.

I'd prefer to see this proposal debated properly on this list first. Also, do you think that is realistic in the time frame for 6.8.2? Adding new entries is easy.

...

Then Cabal would work with future GHCs, with new extensions as yet undreamt of, as well.

...

This would provide the mechanism we need; the policy, i.e. what the extension names mean, should be defined somewhere outside of Cabal.

Ok, but where should they be defined? I'm not sure the right place is in GHC. Language extensions (names and meanings) are something that needs to be negotiated within the community and especially between developers of different Haskell implementations. So I think keeping the list in Language.Haskell.Extension is not such a bad idea. Any Haskell implementation that wants a new common extension can get it included in that module in time for a release.

...

(you would still need to add the new extension names defined in 6.8.1 to the legacy mapping for 6.6 flags).

Yep, I'll do that. Duncan

Ian Lynagh

9 Nov 9 Nov

9:03 a.m.

On Thu, Nov 08, 2007 at 10:42:29PM +0000, Duncan Coutts wrote:

...

On Thu, 2007-11-08 at 14:27 +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.

I'd prefer to see this proposal debated properly on this list first.

Also, do you think that is realistic in the time frame for 6.8.2?

Yes, you just change the type declaration and fix the compilation errors that result. I've done it before and I don't remember running into any problems.

...

...
Then Cabal would work with future GHCs, with new extensions as yet undreamt of, as well.

...
This would provide the mechanism we need; the policy, i.e. what the extension names mean, should be defined somewhere outside of Cabal.

Ok, but where should they be defined?

Stable extensions (e.g. MultiParamTypeClasses) should be described somewhere central, perhaps the haskell.org wiki. New exciting stuff that'll probably have completely different semantics tomorrow should be described in the GHC manual. Thanks Ian

John Meacham

6 Jan 6 Jan

12:51 p.m.

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. (jhc itself understands a subset of the cabal file type and can build libraries based on them with jhc --build-hl). There are a couple other places where a 'newtype String' made more sense too if I recall. 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). John -- John Meacham - ⑆repetae.net⑆john⑈

Duncan Coutts

7 Jan 7 Jan

1 p.m.

In message <20080106175119.GB16859@momenergy.repetae.net> Haskell Libraries , Duncan Coutts 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

6344

Age (days ago)

6407

Last active (days ago)

List overview

Download

10 comments

5 participants

participants (5)

Duncan Coutts
Ian Lynagh
John Meacham
Malcolm Wallace
Manuel M T Chakravarty

new language extensions

tags

participants (5)