Changes between Version 8 and Version 9 of Records/TypePunningDeclaredOverloadedRecordFields


Ignore:
Timestamp:
Mar 12, 2012 4:57:17 AM (3 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)