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

[Adam Gundry]

On 09/07/17 18:36, Ertugrul Söylemez wrote:
>> I mean yes, it's the same as in most OOP languages, but isn't it also
>> bad? There must be a better way...
>>
>> Is there any alternative approach to name collisions coming?
> 
> I think we should start considering what problem we're actually solving
> (the "record problem"), and where all solutions inevitably converge
> toward when it comes to name resolution: ad-hoc overloading.  In
> particular, I think OverloadedLabels is a bad solution, and every other
> special-case solution is similarly going to be bad.
> 
> My opinion is and has always been: just allow type-directed name
> resolution in Haskell.  All naming problems would go away instantly
> without any awkward, inconsistent extensions that need new syntax and
> heavy type-level machinery to work.  C++ is doing it.  Every OOP
> language is doing it.  They do it, because it's useful and convenient.
> Let's do it, too!
> 
> 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

How would you propose to do TDNR instead, then? It's far from clear (to
me at least) how to combine ad-hoc type-based overloading with Haskell's
type inference, which is part of the reason why TDNR proposals have
never been implemented.

There are two basic questions that need to be answered:

 1. When does an identifier get special treatment, as opposed to the
usual name resolution process?

 2. At what point during type inference does an ambiguous name get
resolved, and what impact does that have on the type inference process?

The OverloadedLabels answer to question 1 is that special identifiers
get a syntactic cue (the prefix hash). It's ugly, but it's obvious that
something special is happening. Similarly, the TDNR proposal uses the
dot. We could say that any ambiguous identifier (i.e. one that would
cause a name resolution error at present) gets special treatment, but
that's rather implicit and leads to odd changes in type inference
behaviour if a colliding name is brought into or removed from scope.

The OverloadedLabels answer to question 2 is to use normal type class
constraints to defer resolving the ambiguity to the constraint solver.
This is relatively easy to specify and understand. Few alternatives have
ever been properly specified (in particular, the original TDNR proposal
does not really answer this question).

FWIW, it has been suggested that OverloadedLabels be removed on the
basis that using TypeApplications with a Symbol literal gives a not
completely unreasonable syntax (fromLabel @"bar").

Note that OverloadedLabels as it currently stands does not have much
interaction with records, though that might change in the future (see
discussion on https://github.com/ghc-proposals/ghc-proposals/pull/6).

Adam


-- 
Adam Gundry, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/