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


Ignore:
Timestamp:
Feb 20, 2012 9:21:36 PM (3 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