GitLab

The main idea is that when we unify
    forall a. t1  ~  forall a. t2
we get constraints from unifying t1~t2 that mention a.
We are producing a coercion witnessing the equivalence of
the for-alls, and inside *that* coercion we need bindings
for the solved constraints arising from t1~t2.

We didn't have way to do this before.  The big change is
that here's a new type TcEvidence.TcCoercion, which is
much like Coercion.Coercion except that there's a slot
for TcEvBinds in it.

This has a wave of follow-on changes. Not deep but broad.

* New module TcEvidence, which now contains the HsWrapper
  TcEvBinds, EvTerm etc types that used to be in HsBinds

* The typechecker works exclusively in terms of TcCoercion.

* The desugarer converts TcCoercion to Coercion

* The main payload is in TcUnify.unifySigmaTy. This is the
  function that had a gross hack before, but is now beautiful.

* LCoercion is gone!  Hooray.

Many many fiddly changes in conssequence.  But it's nice.

Also "fixes" tcfail158

Makes tcrun043 work again.

We were never really manipulating the EkCtxt after we had built it,
so it's simpler to just pass the final SDoc.

We now always check against an expected kind. When we really don't know what
kind to expect, we match against a new meta kind variable.

Also, we are more explicit about tuple sorts:
  HsUnboxedTuple                  -> Produced by the parser
  HsBoxedTuple                    -> Certainly a boxed tuple
  HsConstraintTuple               -> Certainly a constraint tuple
  HsBoxedOrConstraintTuple        -> Could be a boxed or a constraint
                                  tuple. Produced by the parser only,
                                  disappears after type checking

This big patch implements a kind-polymorphic core for GHC. The current
implementation focuses on making sure that all kind-monomorphic programs still
work in the new core; it is not yet guaranteed that kind-polymorphic programs
(using the new -XPolyKinds flag) will work.

For more information, see http://haskell.org/haskellwiki/GHC/Kinds

We only use it for "compiler" sources, i.e. not for libraries.
Many modules have a -fno-warn-tabs kludge for now.

* Frontend support (not yet used in the vectoriser)

In particular we don't allow *nested* unboxed tuples, but the
typechecker wasn't actually enforcing that, which confused the
later stages of the compiler.

I also updated the documentation on unboxed tuples.

Basically as documented in http://hackage.haskell.org/trac/ghc/wiki/KindFact,
this patch adds a new kind Constraint such that:

  Show :: * -> Constraint
  (?x::Int) :: Constraint
  (Int ~ a) :: Constraint

And you can write *any* type with kind Constraint to the left of (=>):
even if that type is a type synonym, type variable, indexed type or so on.

The following (somewhat related) changes are also made:
 1. We now box equality evidence. This is required because we want
    to give (Int ~ a) the *lifted* kind Constraint
 2. For similar reasons, implicit parameters can now only be of
    a lifted kind. (?x::Int#) => ty is now ruled out
 3. Implicit parameter constraints are now allowed in superclasses
    and instance contexts (this just falls out as OK with the new
    constraint solver)

Internally the following major changes were made:
 1. There is now no PredTy in the Type data type. Instead
    GHC checks the kind of a type to figure out if it is a predicate
 2. There is now no AClass TyThing: we represent classes as TyThings
    just as a ATyCon (classes had TyCons anyway)
 3. What used to be (~) is now pretty-printed as (~#). The box
    constructor EqBox :: (a ~# b) -> (a ~ b)
 4. The type LCoercion is used internally in the constraint solver
    and type checker to represent coercions with free variables
    of type (a ~ b) rather than (a ~# b)

This patch (and its TH counterpart) implements
   Trac #4429 (lookupTypeName, lookupValueName)
   Trac #5406 (reification of type/data family instances)

See detailed discussion in those tickets.

TH.ClassInstance is no more; instead reifyInstances returns a [Dec],
which requires fewer data types and natuarally accommodates family
instances.

'reify' on a type/data family now returns 'FamilyI', a new data
constructor in 'Info'

Template Haskell doesn't support GADTs directly but
we can use equality constraints to do the job. Here's
an example of the dump from splicing such a declaration:

    [d| data T a b
            where
              T1 :: Int -> T Int Char
              T2 :: a -> T a a
              T3 :: a -> T [a] a
              T4 :: a -> b -> T b [a] |]
  ======>
    T5217.hs:(6,3)-(9,53)
    data T a[aQW] b[aQX]
        = (b[aQX] ~ Char, a[aQW] ~ Int) => T1 Int |
          b[aQX] ~ a[aQW] => T2 a[aQW] |
          a[aQW] ~ [b[aQX]] => T3 b[aQX] |
          forall a[aQY]. b[aQX] ~ [a[aQY]] => T4 a[aQY] a[aQW]

They belonged to the old generic deriving mechanism, so they can go. Adapted a lot of code as a consequence.

See the paper "Practical aspects of evidence based compilation in System FC"

* Coercion becomes a data type, distinct from Type

* Coercions become value-level things, rather than type-level things,
  (although the value is zero bits wide, like the State token)
  A consequence is that a coerion abstraction increases the arity by 1
  (just like a dictionary abstraction)

* There is a new constructor in CoreExpr, namely Coercion, to inject
  coercions into terms

This patch embodies many, many changes to the contraint solver, which
make it simpler, more robust, and more beautiful.  But it has taken
me ages to get right. The forcing issue was some obscure programs
involving recursive dictionaries, but these eventually led to a
massive refactoring sweep.

Main changes are:
 * No more "frozen errors" in the monad.  Instead "insoluble
   constraints" are now part of the WantedConstraints type.

 * The WantedConstraint type is a product of bags, instead of (as
   before) a bag of sums.  This eliminates a good deal of tagging and
   untagging.

 * This same WantedConstraints data type is used
     - As the way that constraints are gathered
     - As a field of an implication constraint
     - As both argument and result of solveWanted
     - As the argument to reportUnsolved

 * We do not generate any evidence for Derived constraints. They are
   purely there to allow "impovement" by unifying unification
   variables.

 * In consequence, nothing is ever *rewritten* by a Derived
   constraint.  This removes, by construction, all the horrible
   potential recursive-dictionary loops that were making us tear our
   hair out.  No more isGoodRecEv search either. Hurrah!

 * We add the superclass Derived constraints during canonicalisation,
   after checking for duplicates.  So fewer superclass constraints
   are generated than before.

 * Skolem tc-tyvars no longer carry SkolemInfo.  Instead, the
   SkolemInfo lives in the GivenLoc of the Implication, where it
   can be tidied, zonked, and substituted nicely.  This alone is
   a major improvement.

 * Tidying is improved, so that we tend to get t1, t2, t3, rather
   than t1, t11, t111, etc

   Moreover, unification variables are always printed with a digit
   (thus a0, a1, etc), so that plain 'a' is available for a skolem
   arising from a type signature etc. In this way,
     (a) We quietly say which variables are unification variables,
         for those who know and care
     (b) Types tend to get printed as the user expects.  If he writes
             f :: a -> a
             f = ...blah...
         then types involving 'a' get printed with 'a', rather than
         some tidied variant.

 * There are significant improvements in error messages, notably
   in the "Cannot deduce X from Y" messages.

This patch finally deals with the super-delicate question of
superclases in possibly-recursive dictionaries.  The key idea
is the DFun Superclass Invariant (see TcInstDcls):

     In the body of a DFun, every superclass argument to the
     returned dictionary is
       either   * one of the arguments of the DFun,
       or       * constant, bound at top level

To establish the invariant, we add new "silent" superclass
argument(s) to each dfun, so that the dfun does not do superclass
selection internally.  There's a bit of hoo-ha to make sure that
we don't print those silent arguments in error messages; a knock
on effect was a change in interface-file format.

A second change is that instead of the complex and fragile
"self dictionary binding" in TcInstDcls and TcClassDcl,
using the same mechanism for existential pattern bindings.
See Note [Subtle interaction of recursion and overlap] in TcInstDcls
and Note [Binding when looking up instances] in InstEnv.

Main notes are here:

  * Note [Silent Superclass Arguments] in TcInstDcls,
    including the DFun Superclass Invariant

Main code changes are:

  * The code for MkId.mkDictFunId and mkDictFunTy

  * DFunUnfoldings get a little more complicated;
    their arguments are a new type DFunArg (in CoreSyn)

  * No "self" argument in tcInstanceMethod
  * No special tcSimplifySuperClasss
  * No "dependents" argument to EvDFunApp

IMPORTANT
   It turns out that it's quite tricky to generate the right
   DFunUnfolding for a specialised dfun, when you use SPECIALISE
   INSTANCE.  For now I've just commented it out (in DsBinds) but
   that'll lose some optimisation, and I need to get back to
   this.

Accompanying patch for template-haskell package is reqd

This major patch implements the new OutsideIn constraint solving
algorithm in the typecheker, following our JFP paper "Modular type
inference with local assumptions".  

Done with major help from Dimitrios Vytiniotis and Brent Yorgey.

The main thing here is to allow us to provide type
signatures for 'deriving' bindings without pain.

To print HsTypes correctly we should remember whether the Kind on
a HsTyVarBndr came from type inference, or was put there by the
user.  See Note [Printing KindedTyVars] in HsTypes.  So instead of
changing a UserTyVar to a KindedTyVar during kind checking, we
simply add a PostTcKind to the UserTyVar.

The change was provoked by Trac #3830, although other changes
mean that #3830 gets a diferent and better error message now.
So this patch is simply doing the Right Thing for the future.

This patch also fixes Trac #3845, which was caused by a *type splice*
not remembering the free *term variables* mentioned in it.  Result
was that we build a 'let' when it should have been 'letrec'.
Hence a new FreeVars field in HsSpliceTy.

While I was at it, I got rid of HsSpliceTyOut and use a PostTcKind
on HsSpliceTy instead, just like on the UserTyVar.

a) Added quasi-quote forms for
      declarations
      types
   e.g.   f :: [$qq| ... |]

b) Allow Template Haskell pattern quotes (but not splices)
   e.g.  f x = [p| Int -> $x |]

c) Improve pretty-printing for HsPat to remove superfluous
   parens.  (This isn't TH related really, but it affects
   some of the same code.)


A consequence of (a) is that when gathering and grouping declarations
in RnSource.findSplice, we must expand quasiquotes as we do so.
Otherwise it's all fairly straightforward.  I did a little bit of
refactoring in TcSplice.

User-manual changes still to come.

Tidy up the way that predicates are handled inside types

This patch implements three significant improvements to Template Haskell.
  
Declaration-level splices with no "$" 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This change simply allows you to omit the "$(...)" wrapper for 
declaration-level TH splices.  An expression all by itself is
not legal, so we now treat it as a TH splice.  Thus you can now
say
	data T = T1 | T2
 	deriveMyStuff ''T

where deriveMyStuff :: Name -> Q [Dec]
This makes a much nicer interface for clients of libraries that use
TH: no scary $(deriveMyStuff ''T).

Nested top-level splices
~~~~~~~~~~~~~~~~~~~~~~~~
Previously TH would reject this, saying that splices cannot be nested:
	f x = $(g $(h 'x))
But there is no reason for this not to work.  First $(h 'x) is run,
yielding code <blah> that is spliced instead of the $(h 'x). Then (g
<blah>) is typechecked and run, yielding code that replaces the
$(g ...) splice.  

So this simply lifts the restriction.

Fix Trac #3467: non-top-level type splices
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

It appears that when I added the ability to splice types in TH
programs, I failed to pay attention to non-top-level splices -- that
is, splices inside quotatation brackets.  

This patch fixes the problem.  I had to modify HsType, so there's a
knock-on change to Haddock.

Its seems that a lot of lines of code has changed, but almost all the
new lines are comments!

General tidying up
~~~~~~~~~~~~~~~~~~
As a result of thinking all this out I re-jigged the data type ThStage,
which had far too many values before.  And I wrote a nice state transition
diagram to make it all precise; 
   see Note [Template Haskell state diagram] in TcSplice

Lots more refactoring in TcSplice, resulting in significantly less code.
(A few more lines, but actually less code -- the rest is comments.)

I think the result is significantly cleaner.

The issue here is this:

  type ItemColID a b = Int  -- Discards a,b

  get :: ItemColID a b -> a -> ItemColID a b
  get (x :: ItemColID a b) = x :: ItemColID a b

The pattern signature for 'x' doesn't actually rigidly bind a,b.
This crashed GHC 6.10 with a 'readFilledBox' panic.  Now we fail
with an erroe message

With the new outside-in algorithm we'll be able to accept this program.

The main purpose of this patch is to fix Trac #3306, by fleshing out the
syntax for GADT-style record declraations so that you have a context in 
the type.  The new form is
   data T a where
     MkT :: forall a. Eq a => { x,y :: !a } -> T a
See discussion on the Trac ticket.

The old form is still allowed, but give a deprecation warning.

When we remove the old form we'll also get rid of the one reduce/reduce
error in the grammar. Hurrah!

While I was at it, I failed as usual to resist the temptation to do lots of
refactoring.  The parsing of data/type declarations is now much simpler and
more uniform.  Less code, less chance of errors, and more functionality.
Took longer than I planned, though.

ConDecl has record syntax, but it was not being used consistently, so I
pushed that through the compiler.

At last!  Trac #1476 and #3177

This patch extends Template Haskell by allowing splices in
types.  For example

  f :: Int -> $(burble 3)

A type splice should work anywhere a type is expected.  This feature
has been long requested, and quite a while ago I'd re-engineered the
type checker to make it easier, but had never got around to finishing
the job.  With luck, this does it.

There's a ToDo in the HsSpliceTy case of RnTypes.rnHsType, where I
am not dealing properly with the used variables; but that's awaiting
the refactoring of the way we report unused names.

A long-standing improvement to the error message for kinds. Now instead of
    Expected kind `* -> *', but `Int' has kind `*'
we get
    The first argument of `T' should have kind `* -> *',
    but `Int' has kind `*'

Ha!

This should fix the build with GHC 6.6

I followed the suggestion in Trac #2994, which took longer than I
expected.  As usual I did a bit of tidying up at the same time,
and improved a few other error reports.

The main bug was in TcHsType; see Note [Avoid name clashes for 
associated data types].  However I did a bit of re-factoring while 
I was abouut it.

I'm still a but unhappy with the use of TyCon.setTyConArgPoss; it'd
be better to construct the TyCon correctly in the first place.  But
that means passing an extra parameter to tcTyDecl1... maybe we should
do this.

- Pattern signatures must be identical to the type expected for the pattern;
  see Note [Pattern coercions]
- We now signal an appropriate error if an equality coercion would be needed
  (instead of just generating Core that doesn't typecheck)

  MERGE TO 6.10

This patch collects several related things together.

* Refactor TcDeriv so that the InstInfo and the method bindings are renamed
  together.  This was messy before, and is cleaner now.  Fixes a bug caused 
  by interaction between the "auxiliary bindings" (which were given 
  Original names before), and stand-alone deriving (which meant that those
  Original names came from a different module). Now the names are purely
  local an ordinary.

  To do this, InstInfo is parameterised like much else HsSyn stuff.

* Improve the location info in a dfun, which in turn improves location 
  info for error messages, e.g. overlapping instances

* Make sure that newtype-deriving isn't used for Typeable1 and friends.
  (Typeable was rightly taken care of, but not Typeable1,2, etc.)

* Check for data types in deriving Data, so that you can't do, say,
 	deriving instance Data (IO a)

* Decorate the derived binding with location info from the *instance* 
  rather than from the *tycon*.  Again, this really only matters with
  standalone deriving, but it makes a huge difference there.

I think that's it.  Quite a few error messages change slightly.

If we release 6.8.4, this should go in if possible.