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/CoherentPrototype.hs -- Adam Gundry, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
