Hi AntC, Thanks for the feedback! On 26/04/13 09:55, AntC wrote:
Adam Gundry
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