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

[Ertugrul Söylemez]

>> 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?

My proposal is *always*: ...


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

... type inference would have to be done multiple times, once for each
matching identifier in scope.  Do each of them independently, then see
which ones turn out to be well-typed (no ambiguity, no missing
instances, no mismatch, etc.).  If there is exactly one, take it,
otherwise give up with a type error.

For regular unique identifiers nothing would change, so this is a
backward-compatible extension.


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

My point is that that's inevitable.  1. nice syntax, 2. simple
semantics, 3. no inference interference -- pick two.

In today's Haskell we have 2 and 3, but we lack 1, because we need to
prefix our identifiers or use qualified imports.  OverloadedLabels seems
to go with 1 and 3, lacking 2, because of the heavy type-level machinery
it relies on.  I propose that we go with 1 and 2 instead.

This can of course cause problems with applications that don't fully
saturate a function.  Since that's common in Haskell, we would have to
use it sparingly, potentially only for record fields or lenses.  But
that's also the primary use case, so I'd be fine with that.


Greets
ertes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20170710/6e8cffc8/attachment.sig>