[nessus42]

So, what you're saying is that we all of parametric polymorphism, ad hoc polymorphism, and subtype polymorphism, right?

You'll get no argument from me, but that doesn't mean that there should be an unfortunate syntactic distinction between the three.

[nessus42]

The above should read, "So, what you're saying is that we need all of [...]".

Sorry about that!

[eli_gottlieb]

I'm saying, what happens if more than one module provides a getOrElse() method?

In "classical" OOP, the type of the "dotted" parameter, the this pointer, the method receiver, tells the compiler to look in its own module/namespace for the method name.

If we just write getOrElse(herp,Darpity), then we now have to either make getOrElse a type-class method (type-classes are equivalent to certain usages of modules) to recover the same functionality of looking up the appropriate method, or we have to write herpModule::getOrElse(herp,Darpity).

[nessus42]

As I understand it, in statically typed languages that support multi-methods, you import the generic function declaration for a multi-method. This multi-method can be defined in zillion different modules. You only have to import the generic function declaration, not any of the function definitions. The generic function declaration can be parameterized, just like parameterized declarations in Scala. Single or multiple dispatch may be used to locate a method definition.

So, yes, your code does need more import statements. I don't consider this to be a problem. Your code, however, does not need to qualify the functions that it calls with the module where the function is defined.

[eli_gottlieb]

You would have to qualify the call with the module where the generic function is defined. Otherwise, you could import two modules that both define a generic function named foo() -- but whose foo() functions do completely different things.

[nessus42]

Yes. I consider this a feature, not a bug.