Skip to content
This repository

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Fetching contributors…

Octocat-spinner-32-eaf2f5

Cannot retrieve contributors at this time

file 182 lines (143 sloc) 6.672 kb
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181

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
    indexed-types/should_compile/T2238:

* Partial applications of data type families
    indexed-types/should_compile/DerivingNewType
  
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
     validate-settings.mk 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
   T1470(normal,optc,hpc,optasm)
   T2494(normal)
   T2494-2(normal,optc,hpc,optasm)
   T3108(normal,hpc,optasm) <- DV: Actually works, but we have a warning for
                                     deprecated flags
   T3391(normal,optc,hpc,optasm)
   tc003(hpc)
   tc081(normal,optc,hpc,optasm) <- DV: Let does not get generalized for
                                         *single* variable binding
   tc089(normal,optc,hpc,optasm)
   tc095(normal,optc,hpc,optasm)
   tc111(normal,optc,hpc,optasm)
   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)
   tc162(normal)
   tc168(normal,optc,hpc,optasm) <- DV: Actually works, don't know why its reported
   tc170(normal)
   tc175(normal,optc,hpc,optasm)
   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 ...
   tc217(normal,optc,hpc,optasm)
   tc222(normal,optc,hpc,optasm)
   tc231(normal,optc,hpc,optasm)
   tc237(normal,optc,hpc,optasm)
   tc243(normal,optc,hpc,optasm) <- DV: Actually works, Definition but no signature warning
   tc244(normal,optc,hpc,optasm)


 

ToDo
~~~~
* zonking Coercions should use a function of a different name

Basic setup
~~~~~~~~~~~
   New modules TcSimplify (old name, but all new code)
TcInteract
                   TcCanonical (defines the TcS monad too)
                   Constraints (both Wanted and Canonical)

Existing modules Coercion (defines operations over Coercions)
Kind
Type
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)
  Consider:
    - 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]
~~~~~~~~~~~~~~~~~~~~~~~
Given

  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?)

Something went wrong with that request. Please try again.