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

Anthony Clayden anthony_clayden at clear.net.nz
Mon Jul 10 02:17:39 UTC 2017


> On Sun Jul 9 20:37:23 UTC 2017, Alexis King wrote:

> > On Jul 9, 2017, at 10:36, Ertugrul Söylemez <esz at
posteo.de> wrote:
> 
> > AND PLEASE not the way an [existing proposal] suggests
to do it!
> > Please let's just do ad-hoc overloading.  There is no
reason to
> > introduce new syntax, because syntax is completely
orthogonal
> > to this problem.
> >
> > [existing proposal]:
> >
https://prime.haskell.org/wiki/TypeDirectedNameResolution

Folks, that is not an existing proposal.
SPJ's write-up is seductive, but fatally flawed,
as Edward Kmett pointed out during the 
OverLoadedRecordFields development work.

Quite apart from its relying on special syntax,
TDNR can't cope with nested records. In:

> ... student.course.instructor ...

the `.course.instructor` is irresolvably ambiguous,
in exactly the same way as `(show . read)`.

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

> If I understand correctly, what you’re proposing is the
“syntax-free”
> variant of TDNR, which is already outlined here:
>
https://ghc.haskell.org/trac/ghc/wiki/SyntaxFreeTypeDirectedNameResolution

I think everyone should read the accompanying discussion.
That turned out to be not an 'outline'
but just a piece of wishful thinking.
It has all the flaws of the original TDNR,
plus a few of its own.

> I agree that would be a very nice feature to have, and I
think doing it
> without new syntax would be strongly preferable to adding
new syntax.
> The proposal outlines the basics of how it would work, but
I have no
> idea how difficult it would be to implement in practice.

Quite.

AntC


More information about the Haskell-Cafe mailing list