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


Ignore:
Timestamp:
Feb 17, 2012 11:38:32 PM (2 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