[Haskell-cafe] Proposal: TypeDirectedNameResolution

Jason Dagit dagit at codersbase.com
Mon Jul 27 12:57:05 EDT 2009

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.

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090727/fd6ec956/attachment.html

More information about the Haskell-Cafe mailing list