Changes between Version 2 and Version 3 of TypeFunctions/IntegratedSolver


Ignore:
Timestamp:
Dec 3, 2008 6:52:08 AM (5 years ago)
Author:
chak
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • TypeFunctions/IntegratedSolver

    v2 v3  
    2121reduceList :: RedEnv -> [Inst] -> Avails -> TcM Avails 
    2222}}} 
     23The `[Inst]` currently includes equalities, but they are ignored.  The `Avails` passed in are free of equalities, but the outgoing ones includes equalities (which come from the `[Inst]`).  Moreover, we have the post-processing of `Avails` by 
     24{{{ 
     25extractResults :: Avails 
     26               -> [Inst]                -- Wanted 
     27               -> TcM (TcDictBinds,     -- Bindings 
     28                       [Inst],          -- The insts bound by the bindings 
     29                       [Inst])          -- Irreducible ones 
     30                        -- Note [Reducing implication constraints] 
     31}}} 
     32The irreducible `Inst`s will include all equalities that are passed in as wanteds. 
     33 
     34=== Integration === 
     35 
     36Both the equality and class solver have a pre-processing and post-processing phase as well as the main solving phase.  (All three phases are structurally more complicated for equalities.) 
     37 
     38==== Pre-processing ==== 
     39 
     40The two tasks: 
     41 * Classes: computation of the initial `Avails` value (called `init_state` in `reduceContext`). 
     42 * Equalities: normalisation of equalities and class constraints. 
     43I'd suggest to do normalisation first (basically in the same way as it done now) and then build the initial `Avails` from the normalised constraints. 
     44 
     45==== Main solver ==== 
     46 
     47We can probably leave the solving of class constraints much as it is now.  How much the solving of equalities will have to change depends on how we handle `Avails` and whether we keep local equalities in `Avails`, too.  (At the moment, the code in `TcTyFuns` doesn't use the `Avails` data type.)  We need to integrate the loops of `TcSimplify.reduceList`/`TCSimplify.reduce` with those of `TcTyFuns.propagate`. 
     48 
     49==== Post-processing ==== 
     50 
     51The two tasks: 
     52 * Classes: Extract bindings, bound insts, and irreducible insts from the final `Avails` (i.e., work of `extractResult`). 
     53 * Equalities: Finalisation phase. 
     54I'd suggest to extract results first and then finalise on the insts as usual.  That way, the code for both probably doesn't have to change much.  It's also conceptually simpler, I think. 
     55 
     56==== Open questions ==== 
     57 
     58 0. During solving we maintain the local equalities and local class constraints in rather different structures.  In particular, we don't use `Avails` for equalities.  How do we want to integrate this? 
     59 0. Integration of loops of `TcSimplify.reduceList`/`TCSimplify.reduce` with those of `TcTyFuns.propagate`. 
    2360 
    2461=== Module structure === 
     
    3168=== Functional dependencies === 
    3269 
    33 Currently, `tcImproveOne` generates pairs of types to be unified (on the basis of the FD improvement rules) and does unify them with `unifyType` (via `unifyEqns`).  In the integrated solver, `tcImproveOne` should generate equality constraints instead.  This will get rid of the `extra_eqs` that we currently have in `reduceContext`. 
     70Currently, `tcImproveOne` generates pairs of types to be unified (on the basis of the FD improvement rules) and does unify them with `unifyType` (via `unifyEqns`).  In the integrated solver, `tcImproveOne` should generate equality constraints (with identity coercions) instead.  This will get rid of the `extra_eqs` that we currently have in `reduceContext`.