Are there GHC extensions we'd like to incorporate wholesale?

[Andres Loeh]

Hi.

Just to add a few general points. There are different dimensions to
evaluate GHC extensions for inclusion in the standard, and just making
lists does not really reflect that. The two most important ones, I
think, are:

1. Whether we think they're actually a good idea or not.

2. Whether we think they're feasible to specify in a sensible way.

There are variations of these points (extensions that are perhaps
possible to specify, but ugly in their current form; extensions that
have subtle interactions with others; ...)

In general, I am in favour on working on extensions for which we
believe they're good ideas, and try to make progress, even if we
cannot include them yet. So just as an example, if we think GADTs (and
not just GADTSyntax) are in principle a good idea and should be in a
future standard, then perhaps we can try to work out what exactly we
feel would be needed to include them, but is still missing. Then even
in times when no standardization process is active, people can look at
this list of issues and try to work on them. I also think that we
should be careful with straight-forward looking syntax extensions.
Just because an extension is easy to specify should not make it an
automatic accept either. The complexity of the language is already
high.

All this being said, I still have a personal list:

BangPatterns
ConstrainedClassMethods
ConstraintKinds (?)
Derive* (?)
EmptyCase
ExistentialQuantification
ExplicitForAll
ExplicitNamespaces
ExtendedDefaultRules (?)
FlexibleContexts
FlexibleInstances
GADTSyntax
InstanceSigs
KindSignatures
NullaryTypeClasses
Overloaded* (?)
PartialTypeSignatures (?)
RankNTypes
ScopedTypeVariables
StandaloneDeriving (?)
TypeSynonymInstances
TypeOperators (?)

I probably forgot a few. For the ones listed with (?), I am aware of
some problems, but I'd still be very happy to at least have some
discussions about them and make some progress in the direction of
future standardization, as I indicated above.

Cheers,
  Andres

On Tue, May 3, 2016 at 7:32 AM, M Farkas-Dyck <m.farkasdyck at gmail.com> wrote:
> On 02/05/2016, Cale Gibbard <cgibbard at gmail.com> wrote:
>> Are there extensions which ought to stop being extensions?
>
>> It may also be best to leave the answer up to the implementations. It is much
>> easier to argue for something like that once the extension has been on by
>> default in GHC and all other implementations for a while and most everyone
>> seems happy leaving it on.
>
> I think in many cases that would defeat the purpose of extensions.
> _______________________________________________
> Haskell-prime mailing list
> Haskell-prime at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime