| Even is suggesting that instead of reporting an error, in the second | case we could use the translation: | | f (A.A { A.a }) = a --> f (A.A { A.a = a }) | | (i.e., when punning occurs with a qualified name, use just the | unqualified part of the name in the pattern)
Yes, that'd be possible. But it seems debatable -- it doesn't *look* as if the pattern (A.A { A.a }) binds 'a' -- and it seems even less desirable in record construction and update. To be concrete, would you expect these to work too?
g a = A.A { A.a } --> g a = A.A { A.a = a } h x a = x { A.a } --> h x a = a { A.a = a }
Oh, I didn't realize that record punning included construction as well. Yeah, that's a little funky looking. I don't mind seeing the binding form and I think a new reader could figure it out without too much trouble but I would be a little confused by the construction form and think a new reader would also be confused.
With -XDisambiguateRecordFields you could say
g a = A.A { a }
which seems better. (But there's no help for record update, since we don’t know which data constructor is involved.)
I didn't know about DisambiguateRecordFields! Looks like that also makes the wildcard work like I want it to. The ghc docs for DisambiguateRecordFields don't make this very clear to me... it talks about disambiguating names in scope, but if I say "R.R { a = val}" I wouldn't expect it to "disambiguate" 'a', which is not in scope at all, to 'R.a' which looks like a completely different name. Rereading the paragraph at 7.3.11 I'm still surprised this works. Maybe add something like: ... preceeding docs ... This also means that if you use qualified imports you can still use unqualified field names. E.g. in the pattern @(R.R { a = a_val })@, @a@ will be disambiguated to @R.a@, even if @R@ is imported qualified. I gather we're not supposed to call them "records" anymore, they're supposed to be something I forget now, but the rest of the ghc docs says records, so...
So my current conclusion is: improve the error message, perhaps suggesting the flag -XDismabiguateRecordFields, but don't add the change you suggest.
Comments?
Sounds good to me. I'll try adding DisambiguateRecordFields and try out the new punning, thanks!