On 22/01/15 05:38, Edward Kmett wrote:
On Wed, Jan 21, 2015 at 4:34 PM, Adam Gundry wrote:
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.
That's a fair point, at least provided one is happy to work with the canonical lens type we choose, because all others will require a combinator. ;-) Actually, the simplifications I recently came up with could allow us to make uses of the field work as van Laarhoven lenses, other lenses *and* selector functions. In practice, however, I suspect this might lead to somewhat confusing error messages, so it might not be desirable. Adam
[1] https://github.com/adamgundry/records-prototype/blob/master/NewPrototype.hs [2] https://github.com/adamgundry/records-prototype/blob/master/CoherentPrototyp...
-- Adam Gundry, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/