> 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?)