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.farkasd...@gmail.com> wrote: > On 02/05/2016, Cale Gibbard <cgibb...@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@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime _______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime