Changes between Version 8 and Version 9 of Records/DeclaredOverloadedRecordFields/ImplementorsView


Ignore:
Timestamp:
Feb 20, 2012 9:02:04 PM (2 years ago)
Author:
guest
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Records/DeclaredOverloadedRecordFields/ImplementorsView

    v8 v9  
    9898}}} 
    9999 
    100 (That is, with a name or expression preceeding the `{ ... }`. A data constructor prefix continues to use 
    101  -XDisambiguateRecordFields.) 
     100(That is, with a name or expression preceeding the `{ ... }`. A data constructor prefix continues to use  -XDisambiguateRecordFields.) 
    102101 
    103102It is crucial to this proposal that we can implement a polymorphic field update function (`set`). There's a number of tricky requirements considered below. 
     
    118117{{{ 
    119118    instance (t ~ (String, String)) => 
    120         Has Customer_NameAddress 
    121               (Proxy_firstName, Proxy_lastName) t     where ... 
     119        Has Customer_NameAddress (Proxy_firstName, Proxy_lastName) t     where ... 
    122120}}} 
    123121 
     
    147145For monomorphic (non-changing) fields, `GetResult` returns `t` and `SetResult` returns `r`, so this amounts to the simpler definitions for `Has/get/set` given earlier. 
    148146 
    149 These 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. 
     147These are type families, not associated types, because in many cases, the result from `get` depends only on `fld` (not `r`), and the result from `set` depends only on the record type `r` (not `t`). In a few cases, the type function must be sensitive to the combination of field type and record type. 
    150148 
    151149The extra `Has` constraint on `set`'s result is to 'improve' `t` by gathering constraints from the type of `set`'s resulting record type. 
    152150 
    153151Note 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. 
    154 So the result from set has that type `inserted'. 
     152So the result from set has that type 'inserted'. 
    155153 
    156154Example, based on field `unit_Price`: 
     
    172170(The method definitions are 'uninteresting', compared to the drama to get the types right.) 
    173171 
    174 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`. 
     172The 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 (and to improve the result from `get`) -- rather than type family `SetResult` and `GetResult`. 
    175173 
    176174This 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. 
     
    192190                   -- improved by the instance constraint 
    193191    type instance SetResult HR Proxy_rev t = HR 
    194                    -- the H-R type is hidded inside HR 
     192                   -- the higer-ranked type is hidded inside HR 
    195193    instance (t ~ ([a_] -> [a_])) =>              -- same as SORF 
    196194        Has HR Proxy_rev t    where 
    197195            get HR{rev} _ = rev 
     196            -- set _ fn HR{..} = HR{rev = fn, ..}  -- compile fails: can't match fn's type to rev's 
    198197}}} 
    199198 
     
    212211See the discussion under <Application Programmer's view> and http://hackage.haskell.org/trac/ghc/wiki/Records/DeclaredOverloadedRecordFields/NoMonoRecordFields. When import/exporting do we need to also export the Proxy_type? If not exported, update syntax cannot be desuggarred to use it.) 
    213212 
    214 === Should application programmers declare instances for `Has'/set? ===  
     213=== Should application programmers declare instances for `Has/set`? ===  
    215214 
    216215Nothing so far suggests they should. (And there's obvious dangers in allowing it.)