GHC support for the new "record" package

[Adam Gundry]

[I should say, in case it wasn't clear from my previous email, that I'm
impressed by Nikita's work, excited to see this discussion revived, and
very keen to find the best solution, whether that builds on ORF or not.
Anyway, back down the rabbit hole...]


On 21/01/15 16:48, Simon Marlow wrote:
> On 21/01/2015 16:01, Johan Tibell wrote:
>> My thoughts mostly mirror those of Adam and Edward.
>>
>> 1) I want something that is backwards compatible.
> 
> Backwards compatible in what sense?  Extension flags provide backwards
> compatibility, because you just don't turn on the extension until you
> want to use it.  That's how all the other extensions work; most of them
> change syntax in some way or other that breaks existing code.

Well, it's nice if turning on an extension flag doesn't break existing
code (as far as possible, and stolen keywords etc. excepted). In
ORF-as-is, this is mostly true, except for corner cases involving
higher-rank fields or very polymorphic code. I think it's something to
aim for in any records design, anonymous or not.


>> 4) There are issues with strictness and unpacking.
> 
> Yes - probably the major drawbacks, along with the lack of type-changing
> updates.

Is there any reason why Nikita's proposal couldn't be extended to
support type-changing update, just like ORF? Though the cases in which
it can and cannot apply are inevitably subtle.

Also, I'd add fields with higher-rank types to the list of missing
features. From a user's perspective, it might seem a bit odd if

    data T = MkT { foo :: forall a . a }

was fine but

    data T = MkT {| foo :: forall a . a |}

would not be a valid declaration. (Of course, ORF can't overload "foo"
either, and maybe this is an inevitable wart.)


>> 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).


Adam

-- 
Adam Gundry, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/