Changes between Version 3 and Version 4 of Records/DeclaredOverloadedRecordFields/COmpareSORF
- Feb 20, 2012 9:32:17 PM (2 years ago)
v3 v4 83 83 === Updating polymorphic/higher-ranked fields === 84 84 85 The prototype for this proposal does includea method of updating Higher-ranked fields. 85 The prototype for this proposal a method of updating Higher-ranked fields. 86 86 87 87 It used an extra type function `SetTy`, with an extra type argument bound from the definition of method `set`: … … 100 100 So, I think that update of polymorphic fields remains problematic. " 101 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?) 102 s to `SetTy` (`_a _b _c ...`). How many is more than enough?) 103 103 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. 105 107 106 108 Is 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?