GHC support for the new "record" package

[Adam Gundry]

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/