Changes between Version 2 and Version 3 of Records/DeclaredOverloadedRecordFields/COmpareSORF


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

note re updating higher-ranked types

Legend:

Unmodified
Added
Removed
Modified
  • Records/DeclaredOverloadedRecordFields/COmpareSORF

    v2 v3  
    8181}}} 
    8282 
     83=== Updating polymorphic/higher-ranked fields === 
     84 
     85The prototype for this proposal does include a method of updating Higher-ranked fields. 
     86 
     87It used an extra type function `SetTy`, with an extra type argument bound from the definition of method `set`: 
     88{{{ 
     89    type family SetTy r fld t _a :: *        -- type of the argument to set into the record 
     90        ... 
     91        set :: fld -> (forall _a. SetTy r fld t _a) -> r -> SetResult r fld t 
     92        ... 
     93    type instance SetTy HR Proxy_rev t _a = [_a] -> [_a] 
     94        ... 
     95        set _ fn HR{..} = HR{rev = fn}        -- now works 
     96}}} 
     97 
     98 SPJ has quickly reviewed the prototype: 
     99  "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]] 
     100  So, I think that update of polymorphic fields remains problematic. " 
     101 
     102(We could scale up the hack by providing arbitrarily many forall-bound type arguments to `SetTy` (`_a _b _c ...`). How many is more than enough?) 
     103 
     104Note that the "(ingenious)" and unscalable "hack" appears only in compiler-generated code. 
     105 
     106Is 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? 
     107 
     108 
     109 
    83110=== Relationship to Type Directed Name Resolution [TDNR] === 
    84111