[Haskell-cafe] Type Directed Name Resolution

[Ketil Malde]

Neil Brown <nccb2 at kent.ac.uk> writes:

> I wonder if special syntax is actually needed for this.  

+1

I think there are two issues here: 1) resolving ambiguities using
types, and 2) inventing a new syntax¹ for it.  It's not clear that
these are at all dependent on each other.

> How much of the language would be broken by adopting the general rule:
> "If the only definitions of f are at the top-level or imported, find the type
> of 'a' and the type of all the in-scope 'f' s.  

My main two use cases are records (which tend to like short non-unique
field names), and duplicated imports.  The latter refers to the minor
annoyance that I need to write

  import qualified Data.ByteString.Lazy.Char8 as L
  import Data.ByteString.Lazy.Char8 (ByteString)

To be able to use unique identifiers unqualified, and still avoid
collision with common prelude functions.

I guess IDEs was another important argument², although one I care less
for personally.

> If there is exactly one match then use it, otherwise it's an error."?

It is maybe possible to do this, but I'm worried about the resulting
error messages - this also needs to fail in a manner that I can
understand and hopefully fix.

I'm somewhat surprised that SPJ isn't commenting on this, after all he
made the proposal, suggested using the dot for its syntax, and offers
to implement it if there is popular support - so surely these things
must have either an explicit or probable resolution.  I'm just unable to
find any evidence for it. (Which is what I asked for slightly upstream
in the thread).

-k

¹ Well, actually inventing a new meaning for an old syntax and
differentiate them by clever usage of spacing.
² And maybe the reason behind the syntax?  Is it easier for IDEs to look
up functions for data than vice versa, or is it just more useful to the
programmer?
-- 
If I haven't seen further, it is by standing in the footprints of giants