[Haskell-cafe] Proposal: TypeDirectedNameResolution

Cale Gibbard cgibbard at gmail.com
Thu Jul 30 09:18:46 EDT 2009

2009/7/28 Sittampalam, Ganesh <ganesh.sittampalam at credit-suisse.com>:
> Cale Gibbard wrote:
>> 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.
> [...]
>> 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 think this idea would severely damage compositionality. One example of
> this is that it would make it substantially less likely that
> subexpressions could be abstracted into a separate declaration without
> giving a type signature to fix the type of the new declaration.
> Ganesh

Ah, now that does seem a rather good point, the worry being that
generalisation happens at the top of that new declaration, thereby
suddenly making more than one of the options typecheck, even though
the function/value being defined is still used at the appropriate

That might be enough of a hindrance to kill the idea, yeah, though I
wonder exactly how often it would happen relative to the annoyance of
always having to make the obvious qualifications. It would be nice to
have as an extension at least, I think, to get a sense for this.

I wouldn't advocate putting anything in a standard which we haven't
actually tried of course. (However, I also think we should also have a
bit less respect in regard to keeping things in line with the
standard, so long as a compliant implementation exists...)

 - Cale

More information about the Haskell-Cafe mailing list