Re: [Haskell-cafe] Proposal: TypeDirectedNameResolution

On Mon, Jul 27, 2009 at 9:29 AM, Cale Gibbard wrote:

2009/7/27 Johannes Waldmann :

...

While browsing Haskell-Prime I found this:

http://hackage.haskell.org/trac/haskell-prime/wiki/TypeDirectedNameResolutio...

...

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. 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 :) 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 :) Jason