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


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

--

Legend:

Unmodified
Added
Removed
Modified
  • Records/DeclaredOverloadedRecordFields/COmpareSORF

    v3 v4  
    8383=== Updating polymorphic/higher-ranked fields ===
    8484
    85 The prototype for this proposal does include a method of updating Higher-ranked fields.
     85The prototype for this proposal originally included a method of updating Higher-ranked fields.
    8686
    8787It used an extra type function `SetTy`, with an extra type argument bound from the definition of method `set`:
     
    100100  So, I think that update of polymorphic fields remains problematic. "
    101101
    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?)
     102 * We could scale up the hack by providing arbitrarily many forall-bound type variables to `SetTy` (`_a _b _c ...`). How many is more than enough?)
    103103
    104 Note that the "(ingenious)" and unscalable "hack" appears only in compiler-generated code.
     104 * But we can't support constraints over the type variables. (Because constraints can't appear on the RHS of a type function instance. Perhaps this could be hacked using Constraints Kinds when they mature? They'd have to be declared on the method `set` within `Has`.)
     105
     106 * Note that the "(ingenious)" and unscalable "hack" appears only in compiler-generated code.
    105107
    106108Is 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?