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

[MarLinn]

On 2017-07-09 21:58, Adam Gundry wrote:
> 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?
>> […]
>>
>> My opinion is and has always been: just allow type-directed name
>> resolution in Haskell.
> […]
> 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?

I want to apologize beforehand for the incoherence of my thoughts. These 
are only titbits I would like to throw into the discussion. Please 
excuse me if they are obvious or distracting for the more knowledgeable 
people here.

The first titbit looks esoteric at first glance. About two months ago, 
Oleg dug up what seems like an old experiment of his. He showed that all 
classes, including fundeps, can be reduced to exactly one, carefully 
chosen class. (thread 
<https://mail.haskell.org/pipermail/haskell-cafe/2017-May/127169.html> 
and link to the article 
<http://okmij.org/ftp/Haskell/TypeClass.html#Haskell1>) Playing around 
with it I realized that a version of this one class is already in base. 
It is non other than IsLabel from OverloadedLabels. In a sense, IsLabel 
is the mother of all classes.

That's not extremely surprising, as classes are basically records with, 
and IsLabel offers a kind of name-directed type resolution the same way 
classes do. What it means to me is that OverloadedLabels might have a 
more fundamental nature than is visible on the surface. Possible 
replacements should be approached with care.

What this also tells me is that, in a way, OverloadedLabels offers the 
inverse of type-directed name resolution. No wonder it's awkward for 
that usecase. But maybe that perspective can lead to more ideas?

The other titbit is much simpler: Isn't it about time to allow explicit 
imports, and more importantly, explicit non-imports for instances? Some 
time ago I fantasised about some special syntax for this, calling the 
(very rough) idea "aspects" (thread 
<https://mail.haskell.org/pipermail/haskell-cafe/2017-May/127006.html>). 
But we needn't go that far. The simplest implementation would entail 
only expanded import/export syntax. That wouldn't really be 
type-directed, but brute-force-directed, but sometime it's better to be 
explicit. And the time where our world is so small that only one 
mathematical truth is enough to rule all code is coming closer and 
closer to it's end.

Just two small ideas. Hope they contribute something.

Cheery,
MarLinn


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20170709/8f41fe7b/attachment.html>