3
$\begingroup$

Anecdotally, Virgill III language forbids overloading since overloading resolution is at odds with the language support of functions as first-class citizen, when resolution can't happen at compile time.
In my book, proper typing of overloaded function resolves this friction. Then, which typing would it be?

Take +, whose type could either be int * int -> int, float * float -> float and some more. Let discard overflow considerations here.

  • Caml "solves" the issue by having two distinctly named functions, + and +.. Ugly, not generic.

  • Haskell's typeclass seems pretty circular. Type would be Num -> Num -> Num, where Num is a type that supports addition. I read that as "+ is defined on types that define +".

  • Why not combining the possible types (union type), where the domains should be disjoint to prevent ambiguity.
    Also, the type could be extended depending on context. For instance, if you import a linear algebra module, Matrix * Matrix -> Matrix would become part of the type.
    Is there some type system along those lines?

Maybe the correct answer is "overloading resolution shall always happen at compile time anyway". In that case, what would be the justification of such a commandment?

$\endgroup$
  • $\begingroup$ Your assumption is that domains are disjoint, but they are not disjoint in common cases. Take for example: $1 \in int$ but $1 \in float$ as well. $\endgroup$ – Apoorv Jan 9 at 18:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.