Neil Brown
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