[Haskell-cafe] I'm afraid of OverloadedLabels.

Anthony Clayden anthony_clayden at clear.net.nz
Mon Jul 10 06:35:05 UTC 2017


> On Mon Jul 10 02:57:02 UTC 2017, Nikita Churaev wrote:

> > You can maybe fix that up with FunDeps
> > or TypeFamilies, but then you lose most of TDNR's
> > benefits (esp not coping with existential quanted fields
> > , which is typically a requirement to cope with
> > OOP-style).
> 
> What benefits exactly are lost?

Hi Nikita, I'm not sure I (or anybody)
has the energy for another round of
the "records debate".

The TDNR (ex-)proposal seems so attractive
because it just doesn't consider in detail
all the complexities.
They're magically swept under the carpet 
with the special dot syntax.
So you might expect TDNR would support 
all of the functionality with H98 field names,
plus having multiple fields of the same name.
But how?

Note the comment on TDNR section 'The Proposal'
"TDNR is not "overloading" in the sense of type classes."
And there were plenty of complaints that it's confusingly
similar-but-different to type classes.

You could look at SPJ's re-working of TDNR [2010]
as SORF [2013]:
https://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/SORF

SORF took advantage of the new Symbol Kinds
(not available in 2010), and tried to be more
type-class-like, with the `Has` class.

One of the motivations with SORF is
"Records with polymorphic fields are very important in
practice,
 so it would be a major wart not to support them."
TDNR just didn't discuss higher-ranked types.
It turned out that was just too hard, even for SORF.
(Or rather for OverloadedRecordFields,
 which is what's being delivered from SORF.)

SORF tries to tackle record update,
for which TDNR said "However I propose not
 to apply it [TDNR] to record update. "
I don't think our cousins in OOP
would be impressed by a records system
in which you can't write polymorphic record updates.
(I.e. a method to update the `firstName` 
 in any record that has that field.)

Actually delivering improvements in GHC
around records is being painfully slow.

`DuplicateRecordFields` has eased the pain a little.
Ironically `OverloadedRecordFields` doesn't tackle
higher-ranked types, nor record updates.
And needs special syntax `#firstName`.

So perhaps TDNR's "benefits" were never
achievable?

ANtC



More information about the Haskell-Cafe mailing list