GHC support for the new "record" package

[Edward Kmett]

On Wed, Jan 21, 2015 at 4:34 PM, Adam Gundry <adam at well-typed.com> 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.

> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20150122/dfdeff69/attachment.html>