Simon Peyton-Jones
writes: Edward, is quite right. Thank you for pointing this out; I hadn’t fully absorbed the consequences of the three-parameter Has class. ...
Thank you Simon, Edward, Adam. There is quite a complex design space (and I apologise for trailing a red herring earlier). Simon/Adam's Plan is (in effect) favouring higher-ranked polymorphism over record nesting/chaining. H-R fields are a limitation because we can't update them either. So I think it's a fair question whether supporting h-r polymorphism is worth the limitations? Edward pointed out earlier, circumstances where lenses:
required inference to flow backwards from the 'field' to the 'record'
So that 'feature' of H98 records we've deliberately abandoned, because:
Let’s review the goal: to allow you to use the same field name in different records.
Therefore we can't have the field determining the record type. We've also abandoned having the field (alone) determine the field's type. I can see a genuine use case for (for example) personId is always Int, irrespective of the record type in which personId appears. (This is a 'silent' feature of H98, because the field can appear in only one record type, so it's moot whether it's the field or field+record determining the field's type.) This would be a strong motivation for overloaded fields refraining from generating the fully polymorphic field selector functions. That is, set -XNoRecordSelectorFunctions, then I could declare: personId :: r { personId :: Int } => r -> Int personId = getFld Or perhaps there could be some way to declare that a given field is always at a specific type? Does this help with Edward's chained/nested records example? Does the field name in the outer record determine the type of the inner? (I guess we're in trouble if the inner is (parametric) polymorphic?)