Skip to content
  • Simon Peyton Jones's avatar
    Refactor coercion holes · a492af06
    Simon Peyton Jones authored
    In fixing Trac #14584 I found that it would be /much/ more
    convenient if a "hole" in a coercion (much like a unification
    variable in a type) acutally had a CoVar associated with it
    rather than just a Unique.  Then I can ask what the free variables
    of a coercion is, and get a set of CoVars including those
    as-yet-un-filled in holes.
    
    Once that is done, it makes no sense to stuff coercion holes
    inside UnivCo.  They were there before so we could know the
    kind and role of a "hole" coercion, but once there is a CoVar
    we can get that info from the CoVar.  So I removed HoleProv
    from UnivCoProvenance and added HoleCo to Coercion.
    
    In summary:
    
    * Add HoleCo to Coercion and remove HoleProv from UnivCoProvanance
    
    * Similarly in IfaceCoercion
    
    * Make CoercionHole have a CoVar in it, not a Unique
    
    * Make tyCoVarsOfCo return the free coercion-hole variables
      as well as the ordinary free CoVars.  Similarly, remember
      to zonk the CoVar in a CoercionHole
    
    We could go further, and remove CoercionHole as a distinct type
    altogther, just collapsing it into HoleCo.  But I have not done
    that yet.
    a492af06