A type variable can be an (unqualified) operator e.g. +.
The lexical syntax is the same as that for variable operators, excluding "(.)",
"(!)", and "(*)". In a binding position, the operator must be
parenthesised. For example:

Back-quotes work
as for expressions, both for type constructors and type variables; e.g. Int `Either` Bool, or
Int `a` Bool. Similarly, parentheses work the same; e.g. (:*:) Int Bool.

Fixities may be declared for type constructors, or classes, just as for data constructors. However,
one cannot distinguish between the two in a fixity declaration; a fixity declaration
sets the fixity for a data constructor and the corresponding type constructor. For example:

infixl 7 T, :*:

sets the fixity for both type constructor T and data constructor T,
and similarly for :*:.
Int `a` Bool.

Function arrow is infixr with fixity 0. (This might change; I'm not sure what it should be.)

7.4.4. Liberalised type synonyms

Type synonyms are like macros at the type level, but Haskell 98 imposes many rules
on individual synonym declarations.
With the -XLiberalTypeSynonyms extension,
GHC does validity checking on types only after expanding type synonyms.
That means that GHC can be very much more liberal about type synonyms than Haskell 98.

You can write a forall (including overloading)
in a type synonym, thus:

GHC currently does kind checking before expanding synonyms (though even that
could be changed.)

After expanding type synonyms, GHC does validity checking on types, looking for
the following mal-formedness which isn't detected simply by kind checking:

Type constructor applied to a type involving for-alls.

Unboxed tuple on left of an arrow.

Partially-applied type synonym.

So, for example,
this will be rejected:

type Pr = (# Int, Int #)
h :: Pr -> Int
h x = ...

because GHC does not allow unboxed tuples on the left of a function arrow.

7.4.5. Existentially quantified data constructors

The idea of using existential quantification in data type declarations
was suggested by Perry, and implemented in Hope+ (Nigel Perry, The Implementation
of Practical Functional Programming Languages, PhD Thesis, University of
London, 1991). It was later formalised by Laufer and Odersky
(Polymorphic type inference and abstract data types,
TOPLAS, 16(5), pp1411-1430, 1994).
It's been in Lennart
Augustsson's hbc Haskell compiler for several years, and
proved very useful. Here's the idea. Consider the declaration:

data Foo = forall a. MkFoo a (a -> Bool)
| Nil

The data type Foo has two constructors with types:

MkFoo :: forall a. a -> (a -> Bool) -> Foo
Nil :: Foo

Notice that the type variable a in the type of MkFoo
does not appear in the data type itself, which is plain Foo.
For example, the following expression is fine:

[MkFoo 3 even, MkFoo 'c' isUpper] :: [Foo]

Here, (MkFoo 3 even) packages an integer with a function
even that maps an integer to Bool; and MkFoo 'c'
isUpper packages a character with a compatible function. These
two things are each of type Foo and can be put in a list.

What can we do with a value of type Foo?. In particular,
what happens when we pattern-match on MkFoo?

f (MkFoo val fn) = ???

Since all we know about val and fn is that they
are compatible, the only (useful) thing we can do with them is to
apply fn to val to get a boolean. For example:

f :: Foo -> Bool
f (MkFoo val fn) = fn val

What this allows us to do is to package heterogeneous values
together with a bunch of functions that manipulate them, and then treat
that collection of packages in a uniform manner. You can express
quite a bit of object-oriented-like programming this way.

7.4.5.1. Why existential?

What has this to do with existential quantification?
Simply that MkFoo has the (nearly) isomorphic type

MkFoo :: (exists a . (a, a -> Bool)) -> Foo

But Haskell programmers can safely think of the ordinary
universally quantified type given above, thereby avoiding
adding a new existential quantification construct.

7.4.5.2. Existentials and type classes

An easy extension is to allow
arbitrary contexts before the constructor. For example:

But when pattern matching on Baz1 the matched values can be compared
for equality, and when pattern matching on Baz2 the first matched
value can be converted to a string (as well as applying the function to it).
So this program is legal:

7.4.5.3. Record Constructors

Here tag is a public field, with a well-typed selector
function tag :: Counter a -> a. The self
type is hidden from the outside; any attempt to apply _this,
_inc or _display as functions will raise a
compile-time error. In other words, GHC defines a record selector function
only for fields whose type does not mention the existentially-quantified variables.
(This example used an underscore in the fields for which record selectors
will not be defined, but that is only programming style; GHC ignores them.)

To make use of these hidden fields, we need to create some helper functions:

The rule for record update is this:
the types of the updated fields may
mention only the universally-quantified type variables
of the data constructor. For GADTs, the field may mention only types
that appear as a simple type-variable argument in the constructor's result
type. For example:

7.4.5.4. Restrictions

There are several restrictions on the ways in which existentially-quantified
constructors can be use.

When pattern matching, each pattern match introduces a new,
distinct, type for each existential type variable. These types cannot
be unified with any other type, nor can they escape from the scope of
the pattern match. For example, these fragments are incorrect:

f1 (MkFoo a f) = a

Here, the type bound by MkFoo "escapes", because a
is the result of f1. One way to see why this is wrong is to
ask what type f1 has:

f1 :: Foo -> a -- Weird!

What is this "a" in the result type? Clearly we don't mean
this:

f1 :: forall a. Foo -> a -- Wrong!

The original program is just plain wrong. Here's another sort of error

f2 (Baz1 a b) (Baz1 p q) = a==q

It's ok to say a==b or p==q, but
a==q is wrong because it equates the two distinct types arising
from the two Baz1 constructors.

You can't pattern-match on an existentially quantified
constructor in a let or where group of
bindings. So this is illegal:

f3 x = a==b where { Baz1 a b = x }

Instead, use a case expression:

f3 x = case x of Baz1 a b -> a==b

In general, you can only pattern-match
on an existentially-quantified constructor in a case expression or
in the patterns of a function definition.
The reason for this restriction is really an implementation one.
Type-checking binding groups is already a nightmare without
existentials complicating the picture. Also an existential pattern
binding at the top level of a module doesn't make sense, because it's
not clear how to prevent the existentially-quantified type "escaping".
So for now, there's a simple-to-state restriction. We'll see how
annoying it is.

You can't use existential quantification for newtype
declarations. So this is illegal:

newtype T = forall a. Ord a => MkT a

Reason: a value of type T must be represented as a
pair of a dictionary for Ord t and a value of type
t. That contradicts the idea that
newtype should have no concrete representation.
You can get just the same efficiency and effect by using
data instead of newtype. If
there is no overloading involved, then there is more of a case for
allowing an existentially-quantified newtype,
because the data version does carry an
implementation cost, but single-field existentially quantified
constructors aren't much use. So the simple restriction (no
existential stuff on newtype) stands, unless there
are convincing reasons to change it.

You can't use deriving to define instances of a
data type with existentially quantified data constructors.
Reason: in most cases it would not make sense. For example:;

data T = forall a. MkT [a] deriving( Eq )

To derive Eq in the standard way we would need to have equality
between the single component of two MkT constructors:

instance Eq T where
(MkT a) == (MkT b) = ???

But a and b have distinct types, and so can't be compared.
It's just about possible to imagine examples in which the derived instance
would make sense, but it seems altogether simpler simply to prohibit such
declarations. Define your own instances!

7.4.6. Declaring data types with explicit constructor signatures

GHC allows you to declare an algebraic data type by
giving the type signatures of constructors explicitly. For example:

Any data type that can be declared in standard Haskell-98 syntax
can also be declared using GADT-style syntax.
The choice is largely stylistic, but GADT-style declarations differ in one important respect:
they treat class constraints on the data constructors differently.
Specifically, if the constructor is given a type-class context, that
context is made available by pattern matching. For example:

data Set a where
MkSet :: Eq a => [a] -> Set a
makeSet :: Eq a => [a] -> Set a
makeSet xs = MkSet (nub xs)
insert :: a -> Set a -> Set a
insert a (MkSet as) | a `elem` as = MkSet as
| otherwise = MkSet (a:as)

A use of MkSet as a constructor (e.g. in the definition of makeSet)
gives rise to a (Eq a)
constraint, as you would expect. The new feature is that pattern-matching on MkSet
(as in the definition of insert) makes available an (Eq a)
context. In implementation terms, the MkSet constructor has a hidden field that stores
the (Eq a) dictionary that is passed to MkSet; so
when pattern-matching that dictionary becomes available for the right-hand side of the match.
In the example, the equality dictionary is used to satisfy the equality constraint
generated by the call to elem, so that the type of
insert itself has no Eq constraint.

Notice that, unlike the situation when declaring an existential, there is
no forall, because the Num constrains the
data type's universally quantified type variable a.
A constructor may have both universal and existential type variables: for example,
the following two declarations are equivalent:

All this behaviour contrasts with Haskell 98's peculiar treatment of
contexts on a data type declaration (Section 4.2.1 of the Haskell 98 Report).
In Haskell 98 the definition

data Eq a => Set' a = MkSet' [a]

gives MkSet' the same type as MkSet above. But instead of
making available an (Eq a) constraint, pattern-matching
on MkSet'requires an (Eq a) constraint!
GHC faithfully implements this behaviour, odd though it is. But for GADT-style declarations,
GHC's behaviour is much more useful, as well as much more intuitive.

The rest of this section gives further details about GADT-style data
type declarations.

The result type of each data constructor must begin with the type constructor being defined.
If the result type of all constructors
has the form T a1 ... an, where a1 ... an
are distinct type variables, then the data type is ordinary;
otherwise is a generalised data type (Section 7.4.7, “Generalised Algebraic Data Types (GADTs)”).

As with other type signatures, you can give a single signature for several data constructors.
In this example we give a single signature for T1 and T2:

data T a where
T1,T2 :: a -> T a
T3 :: T a

The type signature of
each constructor is independent, and is implicitly universally quantified as usual.
In particular, the type variable(s) in the "data T a where" header
have no scope, and different constructors may have different universally-quantified type variables:

The type signature may have quantified type variables that do not appear
in the result type:

data Foo where
MkFoo :: a -> (a->Bool) -> Foo
Nil :: Foo

Here the type variable a does not appear in the result type
of either constructor.
Although it is universally quantified in the type of the constructor, such
a type variable is often called "existential".
Indeed, the above declaration declares precisely the same type as
the data Foo in Section 7.4.5, “Existentially quantified data constructors
”.

As usual, for every constructor that has a field f, the type of
field f must be the same (modulo alpha conversion).
The Child constructor above shows that the signature
may have a context, existentially-quantified variables, and strictness annotations,
just as in the non-record case. (NB: the "type" that follows the double-colon
is not really a type, because of the record syntax and strictness annotations.
A "type" of this form can appear only in a constructor signature.)

Record updates are allowed with GADT-style declarations,
only fields that have the following property: the type of the field
mentions no existential type variables.

As in the case of existentials declared using the Haskell-98-like record syntax
(Section 7.4.5.3, “Record Constructors”),
record-selector functions are generated only for those fields that have well-typed
selectors.
Here is the example of that section, in GADT-style syntax:

The key point about GADTs is that pattern matching causes type refinement.
For example, in the right hand side of the equation

eval :: Term a -> a
eval (Lit i) = ...

the type a is refined to Int. That's the whole point!
A precise specification of the type rules is beyond what this user manual aspires to,
but the design closely follows that described in
the paper Simple
unification-based type inference for GADTs,
(ICFP 2006).
The general principle is this: type refinement is only carried out
based on user-supplied type annotations.
So if no type signature is supplied for eval, no type refinement happens,
and lots of obscure error messages will
occur. However, the refinement is quite general. For example, if we had:

eval :: Term a -> a -> a
eval (Lit i) j = i+j

the pattern match causes the type a to be refined to Int (because of the type
of the constructor Lit), and that refinement also applies to the type of j, and
the result type of the case expression. Hence the addition i+j is legal.

These and many other examples are given in papers by Hongwei Xi, and
Tim Sheard. There is a longer introduction
on the wiki,
and Ralf Hinze's
Fun with phantom types also has a number of examples. Note that papers
may use different notation to that implemented in GHC.

The rest of this section outlines the extensions to GHC that support GADTs. The extension is enabled with
-XGADTs. The -XGADTs flag also sets -XRelaxedPolyRec.

A GADT can only be declared using GADT-style syntax (Section 7.4.6, “Declaring data types with explicit constructor signatures”);
the old Haskell-98 syntax for data declarations always declares an ordinary data type.
The result type of each constructor must begin with the type constructor being defined,
but for a GADT the arguments to the type constructor can be arbitrary monotypes.
For example, in the Term data
type above, the type of each constructor must end with Term ty, but
the ty need not be a type variable (e.g. the Lit
constructor).

It is permitted to declare an ordinary algebraic data type using GADT-style syntax.
What makes a GADT into a GADT is not the syntax, but rather the presence of data constructors
whose result type is not just T a b.

You cannot use a deriving clause for a GADT; only for
an ordinary data type.

However, for GADTs there is the following additional constraint:
every constructor that has a field f must have
the same result type (modulo alpha conversion)
Hence, in the above example, we cannot merge the num
and arg fields above into a
single name. Although their field types are both Term Int,
their selector functions actually have different types:

num :: Term Int -> Term Int
arg :: Term Bool -> Term Int

When pattern-matching against data constructors drawn from a GADT,
for example in a case expression, the following rules apply:

The type of the scrutinee must be rigid.

The type of the entire case expression must be rigid.

The type of any free variable mentioned in any of
the case alternatives must be rigid.

A type is "rigid" if it is completely known to the compiler at its binding site. The easiest
way to ensure that a variable a rigid type is to give it a type signature.
For more precise details see
Simple unification-based type inference for GADTs
. The criteria implemented by GHC are given in the Appendix.