Changes between Version 8 and Version 9 of Records/TypePunningDeclaredOverloadedRecordFields


Ignore:
Timestamp:
Mar 12, 2012 4:57:17 AM (2 years ago)
Author:
AntC
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Records/TypePunningDeclaredOverloadedRecordFields

    v8 v9  
    8484 * The Type must be declared once (within the scope), and is then under regular name control.[[BR]](Probably you're doing this already for critical fields to share.) 
    8585 * The type functions are not associated types, because: 
    86     * GetResult for shared fields depends only on the Field's type (per Customer_id above); 
    87     * SetResult for non-parametric record types does not change the record type. 
     86    * `GetResult` for shared fields depends only on the Field's type (per Customer_id above); 
     87    * `SetResult` for non-parametric record types continues the same record type. 
    8888 * The field selector function also must be declared once, defined punning on the field's type.[[BR]](See below for syntactic sugar to declare these.) 
     89 * Possible '''downside:''' for non-`sharing` fields, what's the risk there's already a Type with the same name (upshifted) __and__ that the name is an 'accidental' clash? 
    8990 
    9091    It is an error to be `sharing` a record field without there being a same-named type in scope. The desugar for the data decl would create the instance to use the Type, but then the instance would fail. 
     
    120121'''Technical capabilities''' and limitations for the `Has` class: 
    121122 * Monomorphic fields can be `get` and `set`. 
    122  * Parametric polymorphic fields can be applied in polymorphic contexts, and can be `set` including changing the type of the record.[[BR]](This uses the SetResult type function.) 
     123 * Parametric polymorphic fields can be applied in polymorphic contexts, and can be `set` including changing the type of the record.[[BR]](This uses the SetResult type function.)[[BR]]To do: provide example with desugarring. 
    123124 * Multiple fields can be updated in a single expression (using familiar H98 syntax), but this desugars to nested updates, which is inefficient. 
    124125 * Pattern matching and record creation using the data constructor prefixed to { ... } work as per H98 (using `DisambiguateRecordFields` and friends). 
     126 * But the types are subtlely different vs. polymorphic update: you must explicitly wrap the types.[[BR]](So this is __not__ backwards compatible. Can we do this?:[[BR]]In `Constr{ fld = e }`, if `e` not type `Fld`, enwrap it with a `Fld` constructor.) 
    125127 * Higher-ranked polymorphic fields (including class-constrained) can be applied in polymorphic contexts, and can be set -- __providing__ they are wrapped in a newtype. Here is SPJ's example: 
    126128 
     
    140142    type instance GetResult HR Rev     = (forall a. [a] -> [a])         -- no can do! not allowed forall's on RHS 
    141143                                                                        -- (and can't do equality constraints on type instances) 
     144    {- ??can we do better -- perhaps an eq constraint on the Has instance: 
     145                 (GetResult HR Rev ~ ([a] -> [a])) => Has ... 
     146       plus a non-commital result for getResult 
     147    -} 
    142148 
    143 {- instead, do explicit newtype wrapping for higher-rank types   -} 
     149{- instead, do explicit newtype wrapping for higher-rank types:   -} 
    144150 
    145151    newtype Rev = Rev (forall a. [a] -> [a])        deriving (Has)