GHC support for the new "record" package

[Simon Marlow]

Adam, do you have any measurements for how much code gets generated for 
a record declaration with ORF, compared with a record declaration in GHC 
right now?  That's one thing that has been a nagging worry for me with 
ORF, but I just don't have any idea if it's a real problem or not.

Under Nikita's proposal, zero code is generated for a record 
"declaration" (since there isn't one), and the lenses are tiny 
expressions too.  There's some boilerplate in the library, but it's 
generated once and for all, and isn't that huge anyway.  The 
lightweightness of it from a code-size standpoint is very attractive.

Cheers,
Simon

On 21/01/15 21:34, Adam Gundry wrote:
> On 21/01/15 18:14, Edward Kmett wrote:
>>      >> 5) I don't know if I want to commit the *language* to a particular lens
>>      >> type.
>>
>>      Agreed, but I don't think this need be an issue for either proposal. We
>>      know from ORF that we can make fields sufficiently polymorphic to be
>>      treated as selector functions or arbitrary types of lenses (though
>>      treating them as van Laarhoven lenses requires either some clever
>>      typeclass trickery in the base library, or using a combinator to make a
>>      field into a lens at use sites).
>>
>>
>> Admittedly that has also been the source of 90% of the complexity of the
>> ORF proposal. There we _had_ to do this in order to support the use as a
>> regular function.
>
> 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).
>
>
>> 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.
>
>
>> 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...
>
> Adam
>
> [1]
> https://github.com/adamgundry/records-prototype/blob/master/NewPrototype.hs
> [2]
> https://github.com/adamgundry/records-prototype/blob/master/CoherentPrototype.hs
>