[Haskell-cafe] Proposal: TypeDirectedNameResolution

[Cale Gibbard]

2009/7/27 Jason Dagit <dagit at codersbase.com>:
>
>
> On Mon, Jul 27, 2009 at 9:29 AM, Cale Gibbard <cgibbard at gmail.com> wrote:
>>
>> 2009/7/27 Johannes Waldmann <waldmann at imn.htwk-leipzig.de>:
>> > While browsing Haskell-Prime I found this:
>> >
>> > http://hackage.haskell.org/trac/haskell-prime/wiki/TypeDirectedNameResolution
>> >
>> > This is not some April Fool's day hoax? Because, it might actually
>> > turn Haskell into a somewhat usable (and marketable) language ...
>> > well, you know what I mean.
>>
>> You would be arguing against it then? ;)
>>
>> > Is there 'ghc -XTypeDirectedNameResolution' yet?
>>
>> I'm pretty sure there is not.
>>
>> I don't really care for this proposal because it involves yet more
>> overloading of (.) which rather annoys me. Composition is by far the
>> most common infix operator in my code, and I consider its choice for
>> module qualification a minor, but irritating mistake. (It makes
>> composition chains with qualified names just that much harder to scan
>> with your eyes.)
>>
>> There was a great related idea on #haskell the other day: Make
>> explicit qualification unnecessary whenever there is a *unique* choice
>> of module qualifications from those imported which would make the
>> expression typecheck. Ambiguities would still need to be qualified,
>> but I feel that this would eliminate 99% of all ugly qualified names
>> from code. It would be especially good in the case of infix operators,
>> which as far as I know, nobody actually enjoys qualifying explicitly.
>
> My biggest fear is that of usability.
>
> If I understand you correctly, then as you change module imports you change
> the meaning of the code in potentially non-obvious ways.  So this isn't too
> different than using unqualified imports and flipping between two modules
> that export the same function.  Except that as you increase the
> 'automatic'ness of it, it has the potential to trip up people.

Well, yes, but only insofar as you can already cause that to happen.
Simply adding a new module import might force you to qualify some
names, as you mention below (and as it can already force you to do),
but will never cause the meaning to otherwise change, since it's not
doing something like picking the first module which works (which would
really be bad). It's only fixing the qualification in places where
there's *exactly one* qualification that would work.

Similarly, removing a module import will not cause the meaning to
change, supposing that the module still compiles, and if you can do
that, you can still be certain that nothing from that module was being
used.

Of course, put the two together in one step, and you can change
semantics arbitrarily, but that's already the case, and I don't think
that's necessarily something to be avoided.

> I think what is the worse case is, you add a module import and suddenly you
> have an error in code that was previously compiling.  Suddenly the
> auto-disambiguate stops working in a chunk of code that was fine before.
> When working with code that others have written this would confuse me.  I
> think I would then start using qualified imports everywhere just to "work
> around" this feature :)

You can already import a module and suddenly need to disambiguate
expressions where a name gets used. This just relieves you of that
responsibility sometimes. Consider the case where you have a module
with a bunch of uses of stuff from Data.List and the Prelude, and you
decide that you need Data.Map for a new function. If you import
Data.Map, all of a sudden, you need to qualify half of the Prelude and
Data.List stuff or it would be ambiguous. (Or import Data.Map
qualified.)

> Yes, I realize it would be an extension, but it would be an extension that I
> suspect I would try to avoid.
>
>>
>> What do people think of this idea? Personally, it really annoys me
>> whenever I'm forced to give explicit module qualifications, and I
>> think this would really help. It would also subsume the
>> DisambiguateRecordFields extension rather handily.
>
> I like explicit module qualifications more or less.  I certainly don't mind
> reading them and I don't care if it takes 2 seconds longer to type
> something.  You asked for my thoughts and there they are :)

Well, thanks :)

I do think some thought has to be put into limiting the power of it,
so that we don't end up with situations where only a computer could
figure out what's going on.

 - Cale