[Haskell-cafe] I'm afraid of OverloadedLabels.
monkleyon at gmail.com
Sun Jul 9 21:04:33 UTC 2017
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
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
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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe