Status update on overloaded records work?

Simon Peyton-Jones simonpj at microsoft.com
Wed Oct 16 06:19:08 UTC 2013


Looping in Adam Gundry, who did the work!

Simon

| -----Original Message-----
| From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of AntC
| Sent: 15 October 2013 22:42
| To: ghc-devs at haskell.org
| Subject: Re: Status update on overloaded records work?
| 
| > Johan Tibell <johan.tibell at ...> writes:
| >
| > I'm curious about the current status of the overloaded records work.
| 
| Hi Johan, I think Adam has documented as he's gone along:
| http://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/Pla
| n
| (And that points to implementation notes.)
| 
| I'll leave Adam/Simon to comment more fully, but from my point of view
| as
| an observer with some 'skin in the game' ...
| 
| > Is the design the same as when the project started?
| 
| No:
| - Higher-Ranked types can't be supported
|   -- and SPJ's initial proposal put a lot of weight on them.
|   There's an easy (IMO) work-round;
|   but it does compromise backward compatibility.
| + Type changing update _is_ supported (with limits)
|   I think that was a justified trade-off for H-R types.
| + Adam has been able to support Lenses.
| 
| - (What I was hoping for but didn't get.)
|   No compiler flag to suppress creating selector functions.
|   This would have allowed records to be declared re-using the same
| name;
|   but left it entirely to the developer as to how to access them.
|   (I was trying to promote the TH and/or Lenses cottage industries.)
| 
| > Did we manage to keep the types simple?
| 
| I guess simplicity is in the eye of the beholder ;-)
| For 'gettable' fields, the sugar is as per SPJ's suggestion.
| There isn't sugar for updating.
| 
| The un-sugared types are pretty gnarly.
| I suspect that'll mean obscure and confusing error messages.
| 
| 
| AntC
| 
| _______________________________________________
| ghc-devs mailing list
| ghc-devs at haskell.org
| http://www.haskell.org/mailman/listinfo/ghc-devs


More information about the ghc-devs mailing list