[Haskell-cafe] Proposal: TypeDirectedNameResolution

[Cale Gibbard]

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.

I can see some corner cases where this might lead to a combinatorial
explosion of possible qualifications to try, however, I have a feeling
that such cases wouldn't really happen in practice.

It is admittedly a bit like a very restricted sort of ad-hoc
polymorphism, but given that the modules are compiled separately, I
think the actual interactions with the workings of the type system are
not really very significant. (It's just like you tried each set of
possible qualifications, compiling the whole thing each time, and
checking to see if there's a unique way to get the module to compile.)

This would mean that if we had, say, Data.List, Data.Map and Data.Set
imported, and there was an occurrence of insert that happened to be
applied to a couple of values and then something known to be a Map, it
would behave as if you'd written Data.Map.insert, because that's the
only thing which could possibly make sense. If there were ambiguity
about which insert you meant, it would still be an error, and you
might have to qualify it explicitly.

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.

 - Cale