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

[wren romano]

On Tue, May 3, 2016 at 2:12 AM, Andres Loeh <mail at andres-loeh.de> wrote:
> 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; ...)

I agree that these two points are what we should really be focusing on
(as well as things like ease of implementation), not just popularity.

For example, much as I love GADTs and would be all for them being
added in some future language report, I do not feel they should be
added this time around. (Though I emphatically and wholeheartedly
support adding GADTSyntax.) The primary reason being that while the
semantics of the data types themselves is easy enough to define,
there's no really sensible way of specifying how type inference should
work for them. GHC has gone back and forth with a bunch of different
inference methods over the years, and I don't think that's really
stabilized yet; so basically we'd be stuck with (a) not giving any
useful specification of what users can expect from inference / what
implementors must provide to be considered "standards compliant", or
(b) requiring some inference strategy that will stifle development
rather than help it.

Similarly, while TypeFamilies are fun to play with, I don't think
they're ready for primetime either. While in theory they are
equivalent to fundeps, in practice they're still playing catchup.
Given the choice, I'd much rather see fundeps be added to the spec,
where we make sure to phrase them in such a way that a viable
implementation could consider fundep syntax to be syntactic sugar for
some underlying story with TypeFamilies. —As for whether I'd actually
be given that choice in the first place, I know there have been issues
in the past about adding fundeps to the report. So far as I know, the
main concern is that implementing them correctly is quite intricate
(as also reflected in the intricacies of getting things like
injectivity for TypeFamilies working). But, if we think it'd be a good
idea to aim for getting some variant of type families into the
standard in a future version, then the complexity of fundeps is
already required (if we're to have a complete story for where
TypeFamilies is currently headed). So adding fundeps now does help
towards the eventual goal of adding type families; even if one day we
think of fundeps as a funny syntactic sugar, like how some of us
already consider the ADT syntax to be a funny syntactic sugar for the
more straightforward GADTSyntax.



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


Many of these are on my personal hit list as well. And most of the
ones that aren't still seem fine to add; the exceptions being:

TypeSynonymInstances — I'm not a fan of this extension since it means
big warnings when teaching people Haskell (just getting them to
recognize that type-synonyms are mere shorthands and not generative
definitions is hard enough; any code using this extension requires
them to recognize that sooner). Though it people really want it...
::shrug::

ExtendedDefaultRules — may be okay, but I haven't used/needed it so
have never thought about it.

FlexibleInstances — I like this and want something very much like it,
but it's somewhat tricksy in practice so may need tweaking. In
particular, I've typically found that non-linear use of type variables
in the instance head is not in fact what people usually want/mean, and
so when such instances are given it leads to usability issues re
inference. Many times what is actually desired is to have a delayed
unification constraint, e.g. @instance (i ~ j) => Monad (IContT i j m)
where...@, where we first match the head (with only linear type
variables) and then after we've committed to selecting this instance
only then do we try to resolve the constraint. Even though the syntax
here is suggestive, I think we should be able to get away with adding
delayed unification constraints on instances without actually needing
any other type equality stuff that GHC does. While the problems I've
encountered with FlexibleInstances have mainly been due to non-linear
type variables, I could also see these delayed unification constraints
being helpful for the portion of FlexibleInstances which allows
non-variables to occur in argument positions; again because matching
on the top-level constructor of the instance head may be enough to
help us ground out the arguments to that constuctor, and we really
want to do that grounding after committing to using the instance
rather than as part of deciding whether to use the instance or not.

Overloaded* — If these are added I'd much rather have these as
"standard language extensions", i.e., they would still need to be
explicitly turned on, rather than being enabled everywhere. While it's
nice to have these extensions available, I very seldom need them, and
in light of that am a bit concerned about a backlash similar to the
one with the FTP.

Speaking of which, are things like the AMP and FTP under our purview
or are they under the CLC?

-- 
Live well,
~wren