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


Ignore:
Timestamp:
Feb 20, 2012 9:32:17 PM (2 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?