[Haskell-cafe] Diving into the records swamp (possible GSoC project)

[Adam Gundry]

Hi AntC,

Thanks for the feedback!


On 26/04/13 09:55, AntC wrote:
>> Adam Gundry <adam.gundry <at> strath.ac.uk> writes:
>> 
>> Hi,
>> 
>> I am hoping to do a GSoC project this year working on GHC, and
>> have been pointed in the direction of the records issue (in
>> particular, the desire to overload field names).
> 
> Heck you're brave!

Or possibly stupid. ;-) That's what I'm trying to figure out. There are
certainly other, less controversial, things I might work on!

Your questions are the kind of detailed issue that I'm tempted to
postpone for the time being, although I guess I can state my prejudices:

> Are you sure you want to step into the aggravated issue of changing 
> the dot operator from being function composition?

I'd prefer to leave dot alone and add a new operator for record
field projection, mostly because I don't relish trying to modify the
parser, but I am open to other opinions.

> Are you going to use explicit type application? ("The type of get is 
> very odd.")

GHC desperately needs explicit type application, but that's another
syntactic minefield; I don't think it matters much for this proposal, in
that it's an implementation detail rather than something that should be
exposed to the user.

> Are you going to handle type-changing update?

I think we need to, though the right solution might well be to punt for
now and implement non-overloaded update alone (i.e. require the user to
explicitly specify the record type being updated when there is
ambiguity). This also works for multiple update, which is an issue
otherwise.


>> The plan would be to implement a solution to the "narrow issue" of
>>  overloaded field names, along the lines of Simon PJ's SORF 
>> proposal
> 
> So has <someone> decided that SORF is the best of those many 
> proposals? I guess it's because it comes with the SPJ ring of 
> confidence?

I should have phrased my message more carefully. By "along the lines of"
SORF I didn't mean to exclude adapting it to take into account your work
on DORF/TPDORF. As I understand it, they both set out to solve the same
basic problem (that Johan outlines so clearly) but differ in the
implementation details. I rather meant to contrast the SORF/DORF
approach with an approach based solely on name-spacing.

Perhaps I should have mentioned that SPJ suggested I look at this,
although I don't think we want to be dictatorial about the final result.


> Before jumping to that decision, I suggest you/your sponsors
> consider the implications of the "NewAxioms" stuff in GHC Head [2] to
> support 'controlled' overlap.
> 
> I think overlap is the only extra feature needed to support the DORF 
> or TPDORF proposals. (Plus the syntactic sugar already outlined in 
> that proposal.)
>
>> This would provide a basis for experimentation with first-class
>> record types.
>
> No: first-class record types needs much more than the SORF proposal.
> In particular it needs a way to extend an existing record to make a
> new one; project a subset of fields; and most important to merge two
> records with some fields in common avoiding doubling-up those fields
> (aka Relational Natural Join).
>
> The DORF/TPDORF proposals are aimed much better as a step towards
> first- class record types. [IMO **]
>
> Oleg/Ralf's HList paper covers all the ground for first-class
> records. It depends heavily on overlaps, which is why the NewAxioms
> stuff would work in really well.

While the NewAxioms stuff looks interesting, it's at an early stage.
Moreover, I'm worried that a records implementation based on desugaring
to an encoding (in the style of HList) will inevitably reveal details of
that encoding to the user. Petr rightly points out the need for good
error messages: these are much easier to generate if the constraints
arising from records are solved in GHC, rather than a library like HList.

There is certainly a long way from this proposal to full-blown
extensible records, and I don't expect to get there in a summer.


> AntC
> 
> 
> [2] http://hackage.haskell.org/trac/ghc/wiki/NewAxioms
> 
> [**] Declaration of interest: I wrote the DORF and TPDORF proposals.

Thanks again for your efforts. From reading the list archives I can see
that a lot of thought and work has gone in to the different proposals,
which definitely will inform the final design.  It would be good if we
could finally make progress on the implementation!

Best regards,

Adam