The Future of Haskell discussion at the Haskell Workshop

[Robert Ennals]

I'd like to add a voice of dissent here.

I would much prefer it if Haskell didn't add specific extensible records 
support - even if it could be done without breaking backwards compatibility.


This is because I believe that extensible records encourage poor style. They 
encourage people to expose the internal representation of their structures, 
allowing users to match on internal fields rather than using accessor 
functions.


One of the things that I like about the current Haskell record system is the 
fact that record selectors are functions. This means that, if I change the 
structure of a type, I can just replace the record selector with a normal 
function.


On a similar line of argument, one change that I think would be nice would be 
for record updaters to also be functions.

Then the following code

x {name1 = bla, name2 = blob}

would translate to the following:

set_name1 bla $ set_name2 blob $ x

This would allow record updates to be overridden in the same way that record 
selectors can be.



Perhaps the best way to get the record extensibility features that people seem 
to want would be to allow record selectors (and updaters) to be in type 
classes, just like other functions.



So in summary, here is my proposal:


No specific "extensible records" system.

Define record update to be a function just like record selection is.

Allow these functions to be in type classes.



-Rob