GitLab

All the work was done by Dan Winograd-Cort.

The main thing is that arrow comamnds now have their own
data type HsCmd (defined in HsExpr).  Previously it was
punned with the HsExpr type, which was jolly confusing,
and made it hard to do anything arrow-specific.

To make this work, we now parameterise
  * MatchGroup
  * Match
  * GRHSs, GRHS
  * StmtLR and friends
over the "body", that is the kind of thing they
enclose.  This "body" parameter can be instantiated to
either LHsExpr or LHsCmd respectively.

Everything else is really a knock-on effect; there should
be no change (yet!) in behaviour.  But it should be a sounder
basis for fixing bugs.

e.g.
        data T = MkT { x,y :: Int }

        f (MkT { x = !v, y = negate -> w }) = v + w

All the flags that 'ways' imply are now dynamic

This patch re-implements implicit parameters via a class
with a functional dependency:

    class IP (n::Symbol) a | n -> a where
      ip :: a

This definition is in the library module GHC.IP. Notice
how it use a type-literal, so we can have constraints like
   IP "x" Int
Now all the functional dependency machinery works right to make
implicit parameters behave as they should.

Much special-case processing for implicit parameters can be removed
entirely. One particularly nice thing is not having a dedicated
"original-name cache" for implicit parameters (the nsNames field of
NameCache).  But many other cases disappear:

  * BasicTypes.IPName
  * IPTyCon constructor in Tycon.TyCon
  * CIPCan constructor  in TcRnTypes.Ct
  * IPPred constructor  in Types.PredTree

Implicit parameters remain special in a few ways:

 * Special syntax.  Eg the constraint (IP "x" Int) is parsed
   and printed as (?x::Int).  And we still have local bindings
   for implicit parameters, and occurrences thereof.

 * A implicit-parameter binding  (let ?x = True in e) amounts
   to a local instance declaration, which we have not had before.
   It just generates an implication contraint (easy), but when
   going under it we must purge any existing bindings for
   ?x in the inert set.  See Note [Shadowing of Implicit Parameters]
   in TcSimplify

 * TcMType.sizePred classifies implicit parameter constraints as size-0,
   as before the change

There are accompanying patches to libraries 'base' and 'haddock'

All the work was done by Iavor Diatchki

This is really a small change, but it touches a lot of files quite
significantly. The real goal is to put the implicitly-bound kind
variables of a data/class decl in the right place, namely on the
LHsTyVarBndrs type, which now looks like

  data LHsTyVarBndrs name
    = HsQTvs { hsq_kvs :: [Name]
             , hsq_tvs :: [LHsTyVarBndr name]
      }

This little change made the type checker neater in a number of
ways, but it was fiddly to push through the changes.

There was one place, in type checking parallel list comprehensions
where we were unifying types, but had no convenient way to use the
resulting coercion; instead we just checked that it was Refl.  This
was Wrong Wrong; it might fail unpredicably in a GADT-like situation,
and it led to extra error-generation code used only in this one place.

This patch tidies it all up, by moving the 'return' method from the
*comprehension* to the ParStmtBlock. The latter is a new data type,
now used for each sub-chunk of a parallel list comprehension.

Because of the data type change, quite a few modules are touched,
but only in a fairly trivial way. The real changes are in TcMatches
(and corresponding desugaring); plus deleting code from TcUnify.

This patch also fixes the pretty-printing bug in Trac #6060

The trouble here is that given

    {-# LANGUAGE DataKinds, TypeFamilies #-}
    data instance Foo a = Bar (Bar a)

we want to get a sensible message that we can't use the promoted 'Bar'
constructor until after its definition; it's a staging error.  Bud the
staging mechanism that we use for vanilla data declarations don't work
here.

Solution is to perform strongly-connected component analysis on the
instance declarations. But that in turn means that we need to track
free-variable information on more HsSyn declarations, which is why
so many files are touched.  All the changes are boiler-platey except
the ones in TcInstDcls.

This is the last major addition to the kind-polymorphism story,
by allowing (Trac #5938)

 type family F a   -- F :: forall k. k -> *
 data T a          -- T :: forall k. k -> *
 type instance F (T (a :: Maybe k)) = Char

The new thing is the explicit 'k' in the type signature on 'a',
which itself is inside a type pattern for F.

Main changes are:

* HsTypes.HsBSig now has a *pair* (kvs, tvs) of binders,
  the kind variables and the type variables

* extractHsTyRdrTyVars returns a pair (kvs, tvs)
  and the function itself has moved from RdrHsSyn to RnTypes

* Quite a bit of fiddling with
     TcHsType.tcHsPatSigType and tcPatSig
  which have become a bit simpler.  I'm still not satisfied
  though.  There's some consequential fiddling in TcRules too.

* Removed the unused HsUtils.collectSigTysFromPats

There's a consequential wibble to Haddock too

This extension is implied by:

  * TypeOperators: so that we can import/export things like (+)
  * TypeFamilies: because associated type synonyms use "type T"
                  to name the associated type in a subordinate list.

RHS of a data type or type synonym declaration.  This can be shared
between type declarations and type *instance* declarations.

This fixes Trac #5937, where a kind variable is mentioned only
in the kind signature of a GADT
   data SMaybe :: (k -> *) -> Maybe k -> * where ...

The main change is that the tcdKindSig field of TyData and TyFamily
now has type Maybe (HsBndrSig (LHsKind name)), where the HsBndrSig
part deals with the kind variables that the signature may bind.

I also removed the now-unused PostTcKind field of UserTyVar and
KindedTyVar.

This fixes Trac #5937, where a kind variable is mentioned only
in the kind signature of a GADT
   data SMaybe :: (k -> *) -> Maybe k -> * where ...

The main change is that the tcdKindSig field of TyData and TyFamily
now has type Maybe (HsBndrSig (LHsKind name)), where the HsBndrSig
part deals with the kind variables that the signature may bind.

I also removed the now-unused PostTcKind field of UserTyVar and
KindedTyVar.

which (finally) fills out the functionality of polymorphic kinds.
It also fixes numerous bugs.

Main changes are:

Renaming stuff
~~~~~~~~~~~~~~
* New type in HsTypes:
     data HsBndrSig sig = HsBSig sig [Name]
  which is used for type signatures in patterns, and kind signatures
  in types.  So when you say
       f (x :: [a]) = x ++ x
  or
       data T (f :: k -> *) (x :: *) = MkT (f x)
  the signatures in both cases are a HsBndrSig.

* The [Name] in HsBndrSig records the variables bound by the
  pattern, that is 'a' in the first example, 'k' in the second,
  and nothing in the third.  The renamer initialises the field.

* As a result I was able to get rid of
     RnHsSyn.extractHsTyNames :: LHsType Name -> NameSet
  and its friends altogether.  Deleted the entire module!
  This led to some knock-on refactoring; in particular the
  type renamer now returns the free variables just like the
  term renamer.

Kind-checking types: mainly TcHsType
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
A major change is that instead of kind-checking types in two
passes, we now do one. Under the old scheme, the first pass did
kind-checking and (hackily) annotated the HsType with the
inferred kinds; and the second pass desugared the HsType to a
Type.  But now that we have kind variables inside types, the
first pass (TcHsType.tc_hs_type) can go straight to Type, and
zonking will squeeze out any kind unification variables later.

This is much nicer, but it was much more fiddly than I had expected.

The nastiest corner is this: it's very important that tc_hs_type
uses lazy constructors to build the returned type. See
Note [Zonking inside the knot] in TcHsType.

Type-checking type and class declarations: mainly TcTyClsDecls
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I did tons of refactoring in TcTyClsDecls.  Simpler and nicer now.

Typechecking bindings: mainly TcBinds
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I rejigged (yet again) the handling of type signatures in TcBinds.
It's a bit simpler now.  The main change is that tcTySigs goes
right through to a TcSigInfo in one step; previously it was split
into two, part here and part later.

Unsafe coercions
~~~~~~~~~~~~~~~~
Usually equality coercions have exactly the same kind on both
sides.  But we do allow an *unsafe* coercion between Int# and Bool,
say, used in
    case error Bool "flah" of { True -> 3#; False -> 0# }
-->
    (error Bool "flah") |> unsafeCoerce Bool Int#

So what is the instantiation of (~#) here?
   unsafeCoerce Bool Int# :: (~#) ??? Bool Int#
I'm using OpenKind here for now, but it's un-satisfying that
the lhs and rhs of the ~ don't have precisely the same kind.

More minor
~~~~~~~~~~
* HsDecl.TySynonym has its free variables attached, which makes
  the cycle computation in TcTyDecls.mkSynEdges easier.

* Fixed a nasty reversed-comparison bug in FamInstEnv:
  @@ -490,7 +490,7 @@ lookup_fam_inst_env' match_fun one_sided ie fam tys
     n_tys = length tys
     extra_tys = drop arity tys
     (match_tys, add_extra_tys)
-       | arity > n_tys = (take arity tys, \res_tys -> res_tys ++ extra_tys)
+       | arity < n_tys = (take arity tys, \res_tys -> res_tys ++ extra_tys)
        | otherwise     = (tys,            \res_tys -> res_tys)

It's not clear whether it's desirable or not, and it turns out that
the way we use coercions in GHC means we tend to lose information
about type synonyms.

You can now say
    data {-# CTYPE "some_header.h" "the C type" #-} Foo = ...

I think it's rare that this will actually be needed. If the
header for a CAPI FFI import includes a
    void f(ctype x);
prototype then ctype must already be defined.

However, if the header only has
    #define f(p) p->j
then the type need not be defined.

But either way, it seems good practice for us to specify the header that
we need.

For now, the syntax is
    type    {-# CTYPE "some C type" #-} Foo = ...
    newtype {-# CTYPE "some C type" #-} Foo = ...
    data    {-# CTYPE "some C type" #-} Foo = ...

This continues the clean up of the front end.  Since they
were first invented, type and data family *instance* decls
have been in the TyClDecl data type, even though they always
treated separately.

This patch takes a step in the right direction
  * The InstDecl type now includes both class instances and
    type/data family instances

  * The hs_tyclds field of HsGroup now never has any family
    instance declarations in it

However a family instance is still a TyClDecl.  It should really
be a separate type, but that's the next step.

All this was provoked by fixing Trac #5792 in the HEAD.
(I did a less invasive fix on the branch.)

These are types that look like "this" and "that".
They are of kind `Symbol`, defined in module `GHC.TypeLits`.

For each type-level symbol `X`, we have a singleton type, `TSymbol X`.

The value of the singleton type can be named with the overloaded
constant `tSymbol`.  Here is an example:

tSymbol :: TSymbol "Hello"

They weren't being lexed any more, but we still had productions!

Previously, only type operators starting with ":" were type constructors,
and writing "+" in a type resulted in a type variable.  Now, type
variables are always ordinary identifiers, and all operators are treated
as constructors.  One can still write type variables in infix form though,
for example, "a `fun` b" is a type expression with 3 type variables: "a",
"fun", and "b".

Writing (+) in an import/export list always refers to the value (+)
and not the type.   To refer to the type one can write either "type (+)",
or provide an explicit suobrdinate list (e.g., "(+)()").  For clarity,
one can also combine the two, for example "type (+)(A,B,C)" is also
accepted and means the same thing as "(+)(A,B,C)" (i.e., export the type
(+), with the constructors A,B,and C).

This is just a tidy-up triggered by #5719.  We were parsing () as a
type constructor, rather than as a HsTupleTy, but it's better dealt
with uniformly as the former, I think.  Somewhat a matter of taste.

See Trac #5720: make the unit unboxed tuple (# #) behave uniformly
with the unit boxed tuple ()

This is actually a change in behaviour, but in a very dark corner,
so I don't think this is going to hurt anyone, and the current
behaviour is deeply strange.

For the moment, the kind of the numerical literals is the type "Word"
lifted to the kind level.  This should probably be changed in the future.

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.

In GHC, this provides an easy way to call a C function via a C wrapper.
This is important when the function is really defined by CPP.

Requires the new CApiFFI extension.

Not documented yet, as it's still an experimental feature at this stage.

* Correct usage of new type wrappers from MkId
* 'VECTORISE [SCALAR] type T = S' didn't work correctly across module boundaries
* Clean up 'VECTORISE SCALAR instance'