GitLab

Fixes Trac #9658

Summary:
This includes pretty much all the changes needed to make `Applicative`
a superclass of `Monad` finally. There's mostly reshuffling in the
interests of avoid orphans and boot files, but luckily we can resolve
all of them, pretty much. The only catch was that
Alternative/MonadPlus also had to go into Prelude to avoid this.

As a result, we must update the hsc2hs and haddock submodules.
Signed-off-by: Austin Seipp <austin@well-typed.com>

Test Plan: Build things, they might not explode horribly.

Reviewers: hvr, simonmar

Subscribers: simonmar

Differential Revision: https://phabricator.haskell.org/D13

In looking at Trac #9063 I decided to re-design the default
instances for associated type synonyms.  Previously it was all
jolly complicated, to support generality that no one wanted, and
was arguably undesirable.

Specifically

* The default instance for an associated type can have only
  type variables on the LHS.  (Not type patterns.)

* There can be at most one default instances declaration for
  each associated type.

To achieve this I had to do a surprisingly large amount of refactoring
of HsSyn, specifically to parameterise HsDecls.TyFamEqn over the type
of the LHS patterns.

That change in HsDecls has a (trivial) knock-on effect in Haddock, so
this commit does a submodule update too.

The net result is good though.  The code is simpler; the language
specification is simpler.  Happy days.

Trac #9263 and #9264 are thereby fixed as well.

This covers things like
   Eq a => blah   and   (?x::Int) => blah
where there is just one predicate. Previously we used an ad-hoc
test to decide whether to parenthesise it, but acutally there is
a much simpler solution: just use the existing precedence mechamism.

This applies both to Type and HsType.

There are three bugs here, one serious

 * We were failing to tidy the type arguments in an IfTyConParent
   This is what was causing Trac #9190.

 * toIfaceTcArgs is careful to suppress kind arguments, but there
   was a clone, tidyToIfaceTcArgs in IfaceSyn which didn't.
   Now the latter goes via the former.

 * When pretty-printing a IfaceDecl for an algebraic data type, and
   doing so in Haskell-98 syntax, we were silently assuming that the
   universal type variables of the TyCon and the DataCon were the
   same. But that has not been true for some time. Result: a very
   confusing display.

   Solution: during the conversion to IfaceSyn, take the opportunity
   to make the universal type variables line up exactly.  This is very
   easy to do, makes the pretty-printing easy, and leaves open the future
   possiblity of not serialising the universal type variables of the
   data constructor.

The (pure) unifier tcUnifyTys returns an idempotent substitution.
But previously the kinds of type variables free in the range of
the subst could have un-substituted kind variables.

This patch fixes that, fixing Trac #9106.

See Note [Finding the substitution fixpoint] in Unify

We now display the foralls of a type if any of the type variables
is polykinded.  This put kind polymorphism "in your face" a bit more
often, but eliminates a lot of head scratching.

The user manual reflects the new behaviour.

This change adds a suggestion
    Possible fix: add a type signature for ‘f’
when we have a GADT-style definition with a
type we can't figure out.

See Note [Suggest adding a type signature] in TcErrors.

This initially came up in the discussion of Trac #8968.

This matches GCC's choice of Unicode quotation marks (i.e. U+2018 and U+2019)
and therefore looks more familiar on the console. This addresses #2507.
Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>

I was too eager when fixing Trac #8566, and dropped too many
equalities on the floor, thereby causing Trac #8705.

The fix is easy: delete code.  Lots of new comments!

The previous updates had the line numbers wrong.

The fix to #8644 makes the original T7594 pass (rightly).
I've added a variant that shouuld and does fail

following
  a) suppressing kind foralls and arguments
  b) better fundep error messages

A tiny bit of fallout from the TypeRep changes with a simple fix: we
don't export typeRep# from Data.Typeable anymore, only
Data.Typeable.Internal
Signed-off-by: Austin Seipp <austin@well-typed.com>

(this is related to #3647)

Almost all are re-orderings of relevant-binding output

       Relevant bindings include
  +      m :: Map (a, b) elt (bound at T3169.hs:12:17)
  +      b :: b (bound at T3169.hs:12:13)
         lookup :: (a, b) -> Map (a, b) elt -> Maybe elt
           (bound at T3169.hs:12:3)
  -      b :: b (bound at T3169.hs:12:13)
  -      m :: Map (a, b) elt (bound at T3169.hs:12:17)