Changes between Version 3 and Version 4 of Commentary/Compiler/Coercions


Ignore:
Timestamp:
Nov 17, 2010 6:05:46 PM (3 years ago)
Author:
simonpj
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Commentary/Compiler/Coercions

    v3 v4  
    102102              | Rec [(Id,CoreExpr)] 
    103103 
    104  
    105  
    106104data Type          -- in TypeRep.lhs 
    107105  = TyVar TyVar 
     
    119117Note that 
    120118 * `Var` can be a type variable, coercion variable, or term variable.  You can tell which with a dynamic test (e.g. `isId :: Var -> Bool`). 
     119 
    121120 * `Lam` is used for type abstractions, coercion abstractions, and value abstractions.  The `Var` can tell you which. 
     121 
    122122 * Type applications (in a term) look like `(App f (Type t))`.  The `(Type t)` part must literally appear there,  with no intervening junk.  This is not statically enforced, but it turns out to be much more convenient than having a constructor `TyApp CoreExpr Type`. 
    123123 
     124OK now the new proposal is to ''treat equality evidence just like any other sort of evidence''. 
     125   * A coercion variable is treated like term-level identifier, not a type-level identifier. (More on what that means below.) 
    124126 
    125  * Treat equality evidence just like any other sort of evidence. 
    126    * A coercion variable is an `Id`, not a `TyVar`. 
    127    * A coercion is an `CoreExpr` whose type is `(s ~ t)` or 
    128    * A function can reu 
     127   * A coercion is an `CoreExpr`, of form `Coercion g`, whose type is `(s ~ t)`, of form `PredTy (EqPred s t)`. 
     128 
     129   * Unlike type applications, coercion applications are not required to have a `(Coercion g)` as the argument.  For example, suppose we have 
     130{{{ 
     131f :: forall a. (a~Int) => a -> Int 
     132id :: forall b. b->b 
     133c :: x~Int 
     134}}} 
     135Then the term `(f x (id (x~Int) c))` would be fine. Notice that the coercion argument is an appplication of the identity function.  (Yes it's a bit contrived.)  In `CoreExpr` form it would look like: 
     136{{{  
     137  App (App (Var f) (Type x)) 
     138      (App (App (Var id) (Type (PredTy (EqPred x Int)))) 
     139           (Var c)) 
     140}}} 
     141 
     142   * Similarly a let-binding can bind a coercion 
     143{{{ 
     144  Let (NonRec c (...a coercion-valued term..)) (...body...) 
     145}}} 
     146 
     147   * Coercion application is call-by value.  Ditto let-bindings.  You must have the evidence before calling the function. 
     148  
     149   * So it doesn't make sense to have recursive coercion bindings. 
     150 
     151   * If we see `Let (NonRec c (Coercion g)) e` we can substitute `(Coercion g)` for any term-level occurrences of `c` in the term `e`, and `g` for `c` in any occurrences of `c` in coercions inside `e`.  (This seems a bit messy.)