On Wed, Jan 21, 2015 at 4:34 PM, Adam Gundry
I'm surprised and interested that you view this as a major source of complexity. From my point of view, I quite liked how the ability to overload fields as both selector functions and arbitrary lenses turned out. Compared to some of the hairy GHC internal details relating to name resolution, it feels really quite straightforward. Also, I've recently worked out how to simplify and generalise it somewhat (see [1] and [2] if you're curious).
I'm actually reasonably happy with the design we wound up with, but the need to mangle all the uses of the accessor with a combinator to extract from the data type is a perpetual tax paid, that by giving in and picking a lens type and not having to _also_ provide a normal field accessor we could avoid.
There is a large design space here, and the main thing Nikita's proposal
brings to the table is slightly different assumptions about what such records should mean. This _could_ let us shed some of the rougher edges of ORF, at the price of having to lock in a notion of lenses.
Yes. It's good to explore the options. For what it's worth, I'm sceptical about blessing a particular notion of lenses unless it's really necessary, but I'm prepared to be convinced otherwise.
For users this means the difference between set (foo.bar) 12 and set (le foo.le bar) 12 -- for some combinator that is hard to pick a name for that turns an accessor into a lens. It means they always have to be cognizant of that distinction. The inability to shed that tax in the other design is the major pain point it has always had for me. The user experience for it is / was going to be bad enough that I have remained concerned about how well the adoption for it would be compared to existing approaches, which have more set up but offer cleaner usage.
I'm on the fence about whether it would be a good idea to burden
Nikita's proposal in the same fashion, but I think it'd be wise to explore it in both fashions. My gut feeling though is that if we tie it up with the same restrictions as ORF you just mostly get a less useful ORF with anonymous record sugar thrown in.
I think there's a sensible story to tell about an incremental plan that starts with something like ORF and ends up with something like Nikita's anonymous records. I'll try to tell this story when I can rub a few more braincells together...
I definitely think there is a coherent story there, but I'm not sure I see a way that such a story could end that avoids the concerns above. I very much agree that it makes sense to keep both options on the table though so that we can work through the attendant issues and trade-offs. -Edward