Changes between Version 1 and Version 2 of Records/DeclaredOverloadedRecordFields/ImplementorsView


Ignore:
Timestamp:
Feb 17, 2012 11:38:32 PM (4 years ago)
Author:
guest
Comment:

publish, needs links

Legend:

Unmodified
Added
Removed
Modified
  • Records/DeclaredOverloadedRecordFields/ImplementorsView

    v1 v2  
    145145
    146146These are type families, not associated types, because in many cases, the result from `get` depends only on `fld`, and the result from `set` depends only on the record type `r`. In a few cases, the type function must be sensitive to the combination of field type and record type.
    147 The extra Has constraint on set's result is to 'improve' `t' by gathering constraints from the type of set's resulting record type.
    148 Note that the field value's type `t' is the type to-be in the result, _not_ the type as-was in the record being updated.
     147
     148The extra `Has` constraint on set's result is to 'improve' `t` by gathering constraints from the type of `set`'s resulting record type.
     149
     150Note that the field value's type `t` is the type to-be in the result, _not_ the type as-was in the record being updated.
    149151So the result from set has that type `inserted'.
    150 Example, based on field unit_Price:
     152
     153Example, based on field `unit_Price`:
     154{{{
    151155    data Customer_Price a = Num a => Cust_Price {
    152156                                       ...,
     
    161165            get Cust_Price{unit_Price} _ = unit_Price
    162166            set _ x Cust_Price{..} = Cust_Price{ unit_Price = x, .. }
     167}}}
     168
    163169(The method definitions are 'uninteresting', compared to the drama to get the types right.)
    164 The extra complexity to support changing type could be somewhat reduced using a separate `Set' class with four type parameters, including both as-was and resulting record types, and equality constraints to improve them -- rather than type family SetResult.
    165 This would mean, though, that the type sugar for Has constraints would not be adequate. Since that sugar is to be visible but the instance definitions are to be 'internal', this proposal prefers to support the sugar.
    166 
    167 Selecting polymorphic/higher-ranked fields
     170
     171The extra complexity to support changing type could be somewhat reduced using a separate `Set` class with four type parameters, including both as-was and resulting record types, and equality constraints to improve them -- rather than type family `SetResult`.
     172
     173This would mean, though, that the type sugar for `Has` constraints would not be adequate. Since that sugar is to be visible but the instance definitions are to be 'internal', this proposal prefers to support the sugar.
     174
     175=== Selecting polymorphic/higher-ranked fields ===
     176
    168177Note that initialising records with polymorphic fields (using record constructor syntax) is not affected. This proposal implements selecting/applying those fields in polymorphic contexts. This includes fields with class-constrained types 'sealed' within the record.
     178
    169179To support higher-ranked fields, this proposal follows SORF's approach (with three parameters to Has) to obtain a polymorphic type:
     180{{{
    170181    data HR     = HR {rev :: forall a_. [a_] -> [a_]}   -- per SPJ
    171182    fieldLabel rev :: r -> (forall a_. [a_] -> [a_])
     
    182193        Has HR Proxy_rev t    where
    183194            get HR{rev} _ = rev
    184 
    185 Updating polymorphic/higher-ranked fields
     195}}}
     196
     197=== Updating polymorphic/higher-ranked fields ===
     198
    186199The prototype for this proposal does include a method of updating Higher-ranked fields. SPJ has quickly reviewed the prototype:
    187 "Your trick with SetTy to support update of polymorphic fields is, I belive, an (ingenious) hack that does not scale. I think it works only for fields that are quantified over one type variable with no constraints.
    188 So, I think that update of polymorphic fields remains problematic. "
     200  "Your trick with SetTy to support update of polymorphic fields is, I belive, an (ingenious) hack that does not scale. I think it works only for fields that are quantified over one type variable with no constraints.[[BR]]
     201  So, I think that update of polymorphic fields remains problematic. "
     202
    189203Note that the "(ingenious)" and unscalable "hack" appears only in compiler-generated code.
     204
    190205Is it a requirement to be able to update polymorphic fields? Is it sufficient to be able to update other (monomorphic) fields in records that also contain poly fields?
    191206
    192 Representation hiding/import/export
     207=== Representation hiding/import/export ===
     208
    193209See the discussion under <Application Programmer's view> and <No Mono Record Fields>. When import/exporting do we need to also export the Proxy_type? If not exported, update syntax cannot be desuggarred to use it.)
    194210
    195 Should application programmers declare instances for `Has'/set?
     211=== Should application programmers declare instances for `Has'/set? ===
     212
    196213Nothing so far suggests they should. (And there's obvious dangers in allowing it.)
     214
    197215But updating through virtual fields might need it. See <DORF -- comparison to SORF>#<Virtual record selectors>.
    198216