> 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!

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

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


[2] http://hackage.haskell.org/trac/ghc/wiki/NewAxioms

[**] Declaration of interest: I wrote the DORF and TPDORF proposals.

Haskell-Cafe mailing list

Reply via email to