Fetching contributors…
Cannot retrieve contributors at this time
182 lines (143 sloc) 6.52 KB
Notes on the new type constraint solver
* 1/9/10: Consider
{alpha} [b] (c~b) => (alpha ~ b)
Then to maximise the chance of floating the equality out of
the implication we'd like to orient the given as (b~c)
rather than (c~b).
See test gadt-escape1, gadt13, gadt7
These tests pass because of approximateImplications
* Equality superclasses are not getting the right instance decl
* Partial applications of data type families
Functional dependencies
* indexed-types/Gentle
RelaxedPolyRec by default
* tcfail071
* tcfail144
* tcfail149, 150
* 18/8/10: Fixed treatment of new work list from superclasses of wanteds.
TODO TODO: Revisit the desugarer to deal with equalities that
may mention recursive dictionaries.
* 12/8/10: Fixed proper kind checking for equalities and type family equalities.
NOTE: Type synonyms stay unexpanded in canonical constraints. Is this correct?
* 24/7/10: canonicalisation orients meta variables
kind checking?
see trySpontaneous: need to take care with orientation
* See newWantedSCWorkList: no adding superclass equalities
for wanteds. Seems ad hoc.
* Happy genericTemplate notHappyAtAll needs a signature
* time package needs signatures; I have put -XNoMonoLocalBinds in for now
Improve error message
FD1(normal) <- DV: Failure to produce FD equality from *given* and top-level
FD2(normal) <- DV: Failure to produce FC equality from two *givens*
Unexpected failures:
PolyRec(normal,hpc,optasm) <- DV: Actually works, but we have a warning
for -XRelaxedPolyRec deprecated flag
T3108(normal,hpc,optasm) <- DV: Actually works, but we have a warning for
deprecated flags
tc081(normal,optc,hpc,optasm) <- DV: Let does not get generalized for
*single* variable binding
tc113(normal,optc,hpc,optasm) Generalize top-level var binding
tc127(normal,optc,hpc,optasm) <- DV: Missing module Maybe in haskell98 package ...
tc132(normal,optc,hpc,optasm) Generalize top-level var binding
tc150(normal,optc,hpc,optasm) Pattern signatures
tc159(normal,optc,hpc,optasm) <- ILL FORMED EVIDENCE (related to newtype ... deriving)
tc168(normal,optc,hpc,optasm) <- DV: Actually works, don't know why its reported
tc189(normal,optc,hpc,optasm) <- higher-rank ?
tc192(normal,optc,hpc,optasm) <- loop in desugarer
tc194(normal,optc,hpc,optasm) <- polymorphic pattern signatures / higher-rank?
tc211(normal,optc,hpc,optasm) <- polymorphic pattern signatures / higher-rank?
tc216(normal,optc,hpc,optasm) <- ctx stack depth exceeded ...
tc243(normal,optc,hpc,optasm) <- DV: Actually works, Definition but no signature warning
* zonking Coercions should use a function of a different name
Basic setup
New modules TcSimplify (old name, but all new code)
TcCanonical (defines the TcS monad too)
Constraints (both Wanted and Canonical)
Existing modules Coercion (defines operations over Coercions)
TypeRep (the representation of types, kinds, coercions)
Dead modules TcTyFuns
TcSimplify-old.lhs (the old TcSimplify,
in repo just for reference)
Significant differences wrt the prototype
* "Givens" are simply evidence variables (EvVar)
"Wanteds" are WantedConstraints
See the Implication type in TcSolverTypes.lhs
There is no sum type combining given and wanted constraints
* Wanted constraints are of three flavours (see data WantedConstraint)
- evidenence variables: we can abstract over these
- implications: we can't abstract over these
- literal and method constraints; we can't abstract over these
either, and they aren't implemented yet
* We use a mutable group of bindings attached to each Inplication as the
place to accumulate evidence for dictionaries and implicit parameters
(It's also vital for equality superclasses.) Each Impliciation has a
TcEvBinds, defined in hsSyn/HsBinds. The reference cell to accumulate
bindings into is carried by the TcS solver monad; we need to fill in
evidence in the solver.
* An evidence variable is
- a dictionary
- an implicit paramter
- a coercion variable
See newEvVar in Inst.lhs
* The main Tc monad carries a set of untouchables
The unifier ensures that they are not unified
See Note [Unifying untouchables]
* tcCheckExpr does deep-skol on expected type, and
then calls tcExpr with (Check ty), where ty is deeply-skolemised
Things to check later
* Monomorphism restriction puts type variables in the top level env
When generalising, we can't generalise over these ones (alas)
- Reject programs that fall under the monomorphism restriction
(top-level monomorphic is rare)
- Some hack to accept H98 programs
* No orientation of tv~ty constraints; we don't need it
Note [OpenSynTyCon app]
type family T a :: * -> *
the two types (T () a) and (T () Int) must unify, even if there are
no type instances for T at all. Should we just turn them into an
equality (T () a ~ T () Int)? I don't think so. We currently try to
eagerly unify everything we can before generating equalities; otherwise,
we could turn the unification of [Int] with [a] into an equality, too.
We need to both 'unBox' and zonk deferred types. We need to unBox as
functions, such as TcExpr.tcMonoExpr promise to fill boxes in the expected
type. We need to zonk as the types go into the kind of the coercion variable
`cotv' and those are not zonked in Inst.zonkInst. (Maybe it would be better
to zonk in zonInst instead. Would that be sufficient?)