Changes between Version 3 and Version 4 of Records/OverloadedRecordFields/Plan


Ignore:
Timestamp:
Jun 17, 2013 4:42:54 PM (21 months ago)
Author:
simonpj
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Records/OverloadedRecordFields/Plan

    v3 v4  
    1818}}} 
    1919 
     20=== Record field constraints ===  
     21 
    2022If the flag `-XOverloadedRecordFields` is enabled, a new form of 'record field' constraints `r { x :: t } :: Constraint` are available where `r` and `t` are types, while `x` is a literal string.  These are not typeclass constraints and do not have instances as such (though see the discussion below about virtual record fields). They can appear in contexts in the usual way (that is, they are a new primitive, like equality constraints or implicit parameter constraints). Multiple fields may be written comma-separated in a single constraint as in `r { x :: t, y :: u }`. 
    2123 
     
    3537Don't forget that the `r` might be an arbitrary type not just a type variable or type constructor.  For example, `(Has (T (Maybe b)) "x" [Maybe v])` is a perfectly fine (and soluble) constraint.  I suppose that its shorthand looks like `T (Maybe v) { x :: [Maybe v] }` 
    3638'''End of SLPJ''' 
     39 
     40=== Record field projections ===  
    3741 
    3842Record field constraints are introduced by projections, which are written using a new left-associative infix operator `(.>)`.  That is, if `e :: r` then `e.>x :: r { x :: t } => t`.  This operator must always be applied to (at least) its second argument, so `(.>)` is invalid but `(.>x) :: forall a b . a { x :: b } => a -> b`.