Changes between Version 29 and Version 30 of Records/OverloadedRecordFields/Plan


Ignore:
Timestamp:
Aug 7, 2013 1:59:27 PM (9 months ago)
Author:
adamgundry
Comment:

alpha-conversion for clarity

Legend:

Unmodified
Added
Removed
Modified
  • Records/OverloadedRecordFields/Plan

    v29 v30  
    107107=== Higher-rank fields === 
    108108 
    109 Higher-rank fields, such as 
    110  
    111 {{{ 
    112 data T = MkT { x :: forall a . a -> a } 
    113 }}} 
    114  
    115 cannot be overloaded. If such a field is declared in a module with `-XOverloadedRecordFields` enabled, a warning will be emitted and no selector produced. The user can always declare the selector function manually. 
     109Higher-rank fields, such as in the declaration 
     110 
     111{{{ 
     112data U = MkU { x :: forall a . a -> a } 
     113}}} 
     114 
     115cannot be overloaded. If such a field is in scope for a module with `-XOverloadedRecordFields` enabled, no Has or Upd instances will be produced. The user can always declare the selector function manually. This is similar to the current situation for existentially quantified variables in fields, which do not give rise to selector functions at all. 
    116116 
    117117Bidirectional type inference for higher-rank types relies on inferring the type of functions, so that types can be pushed in to the arguments. However, the type of an overloaded field cannot immediately be inferred (as some constraint solving is required). This is why higher-rank and overloaded fields are incompatible. 
     
    154154}}} 
    155155 
    156 For example, the datatype `T` above would give rise to these instances: 
    157  
    158 {{{ 
     156For example, the datatype `T` would give rise to these instances: 
     157 
     158{{{ 
     159data T a = MkT { x :: [a] } 
     160 
    159161type instance SetResult (T a) "x" [c] = T c 
    160162 
     
    163165}}} 
    164166 
    165 If a type variable is shared by multiple fields, it cannot be changed using `setField`. Moreover, the use of the `SetResult` type family means that phantom type variables cannot be changed. For example, 
    166  
    167 {{{ 
    168 data U a b c = MkU { foo :: (a, b), bar :: a } 
     167If a type variable is shared by multiple fields, it cannot be changed using `setField`. Moreover, the use of the `SetResult` type family means that phantom type variables cannot be changed. For example, in 
     168 
     169{{{ 
     170data V a b c = MkV { foo :: (a, b), bar :: a } 
    169171}}} 
    170172 
     
    173175 
    174176{{{ 
    175 type instance SetResult (T a b c) "foo" (a, b') = T a b' c 
    176  
    177 instance t ~ (a, b') => Upd (T a b c) "foo" t where 
     177type instance SetResult (V a b c) "foo" (a, b') = V a b' c 
     178 
     179instance t ~ (a, b') => Upd (V a b c) "foo" t where 
    178180  setField _ r e = r { foo = e } 
    179181}}}