[Haskell-cafe] Name overloading

[Cristiano Paris]

Hi,

these days I'm thinking about name scoping in Haskell and a question
built up silently but steadily in my mind.

Many times I see code like this:

data Foo = { fooBar :: Int, fooSay :: String, fooClose :: String }

which reminds me of "Ye Olde Times" of C where you prepend the
structure name (or an abbreviation) to the structure's fields so as to
avoid clashes with other (possibly included) structures (here Haskell
qualified imports don't help as they just let you cut down the size of
the prefix which is still present though and is module-scoped anyway).

One of the most appreciated (at least by me) features of OOP languages
like C++, Java, Python and co. is the possibility to name instance
methods the same in different classes and have the compiler resolve to
the correct implementation (at least indirectly through a virtual
table when inheritance is in place) simply looking at the type of the
variable which "->" is applied to. The most fulgid example of this is
the "open" method, which is likely to be present in lots of classes.

Now, in Haskell we have type inference, which is "The Good Thing" as
it allows to "validate" your program at compile time. Hence, the idea
coming up to my mind is that type inference actually forbids a
type-directed resolution of names as in C++ or Java.

Is this correct?

Think about this piece of code:

data DB = { open :: DBHandle }
data FS = { open :: File }

foo x = open x

or, worse:

foo x = open (open x)

if the result of the first "open" application should typecheck with
the second. Notice that, in my understanding, adding a signature
doesn't help as the type checker must guarantee that "foo" code
complies with its signature, which is actually impossible if open is
left undetermined in its type.

Thank you for any comment.

Cristiano