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 and link to the article) 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.

Cheery,
MarLinn