thoughts on the record update problem

Barney Hilken b.hilken at
Thu Mar 8 19:15:20 CET 2012

> This worries me:
> 3. The syntax of record updates must be changed to include the class:
>       r {Rcls| n1 = x1, n2 = x2}

This is really the core of the proposal. If my understanding of the problem is at all accurate, the whole reason we have trouble is that update is dependent on the class, and the Haskel98 syntax doesn't give you enough information to determine what the class is. You could always add an ad-hoc rule which says something like "if there is only one record class in scope which uses all the labels in the update, assume that one" but it would lead to horribly fragile code.

> And if I understand correctly this proposal is still uncertain on some
> edge cases.

According to SPJ, the new version of impredicative polymorphism should allow us to use polymorphic types in contexts, which fixes the only problem I know of. Unfortunately, we can't yet experiment with it, since we won't know the details until the Haskel Symposium. If you have any other "edge cases", please let me know what they are!

> I think it is time to close down the records discussion on the mail
> list and ask for an implementation
> The implementer should use any means at their disposal, probably by
> adding a new construct to the language. However, for now any new
> constructs or other implementation details should be kept internal so
> that we can maintain flexibility going forward.
> A lot of smart people are expending a huge amount of mental effort
> discussing how to shoehorn this problem into the existing Haskell
> machinery and the fine details of the best way to do it even though
> there is still no truly satisfactory solution. I would really like to
> see this effort instead go into an implementation.

This attitude is one I can't even begin to understand. How can you implement something before understanding it? What are you going to implement? Trying to "close down discussion" when no conclusion has been reached is not the action of a healthy community!


More information about the Glasgow-haskell-users mailing list