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! Are you sure you want to step into the aggravated issue of changing the dot operator from being function composition? Are you going to use explicit type application? ("The type of get is very odd.") Are you going to handle type-changing update?
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? 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. AntC [2] http://hackage.haskell.org/trac/ghc/wiki/NewAxioms [**] Declaration of interest: I wrote the DORF and TPDORF proposals.