Field accessor type inference woes

[AntC]

> Simon Peyton-Jones <simonpj <at> microsoft.com> 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?)