Overloaded record fields

[AntC]

> Edward Kmett <ekmett <at> gmail.com> writes:
> 
> Let me take a couple of minutes to summarize how the lens approach 
tackles the composition problem today without requiring confusing changes 
in the lexical structure of the language. 

Thank you Edward, I do find the lens approach absolutely formidable. And I 
have tried to read the (plentiful) documentation. But I haven't seen a 
really, really simple example that shows the correspondence with H98 
records and fields -- as simple as Adam's example in the wiki. (And this 
message from you doesn't achieve that either. Sorry, but tl;dr, and there 
isn't even a record decl in it.)

Does the lens approach meet SPJ's criteria of:
 * It is the smallest increment I can come up with that
   meaningfully addresses the #1 pain point (the inability to
   re-use the same field name in different records).

 * It is backward-compatible.

[I note BTW that as the "Plan" currently stands, the '.field' postfix 
pseudo-operator doesn't rate too high on backward-compatible.]

I do think that freeing up the name space by not auto-generating a record-
type-bound field selector will help some of the naming work-rounds in the 
lens TH.

> ...

You say:
> 
>  template-haskell functions for lens try to tackle the SORF/DORF-like 
aspects. These are what Greg Weber was referring to in that earlier email. 
> 

errm I didn't see an email from Greg(?)

AntC