<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
On 2017-07-09 21:58, Adam Gundry wrote:<br>
<blockquote
cite="mid:f0b27e4d-aac9-e4b1-5271-895b3d19ed0e@well-typed.com"
type="cite">
<pre wrap="">On 09/07/17 18:36, Ertugrul Söylemez wrote:
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">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?
</pre>
</blockquote>
<pre wrap="">[…]
My opinion is and has always been: just allow type-directed name
resolution in Haskell.
</pre>
</blockquote>
<pre wrap="">[…]
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?
</pre>
</blockquote>
<br>
<p>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.</p>
<p>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. (<a
href="https://mail.haskell.org/pipermail/haskell-cafe/2017-May/127169.html">thread</a>
and <a
href="http://okmij.org/ftp/Haskell/TypeClass.html#Haskell1">link
to the article</a>) Playing around with it I realized that a
version of this one class is already in base. It is non other than
<tt>IsLabel</tt> from <tt>OverloadedLabels</tt>. In a sense, <tt>IsLabel</tt>
is the mother of all classes.<br>
</p>
<p>That's not extremely surprising, as classes are basically records
with, and <tt>IsLabel</tt> offers a kind of name-directed type
resolution the same way classes do. What it means to me is that <tt>OverloadedLabels</tt>
might have a more fundamental nature than is visible on the
surface. Possible replacements should be approached with care.<br>
</p>
<p>What this also tells me is that, in a way, <tt>OverloadedLabels</tt>
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?</p>
<p>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" (<a
href="https://mail.haskell.org/pipermail/haskell-cafe/2017-May/127006.html">thread</a>).
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.</p>
<p>Just two small ideas. Hope they contribute something.</p>
<p>Cheery,<br>
MarLinn</p>
<p> </p>
<p><br>
</p>
</body>
</html>