Both reasons have practical impact. For the first one, using erasure
semantics means that the programmer also can discard types when
understanding the runtime behaviour of a program.
Actually, what I had in mind is exclusivelly compile-time overloading, which causes no overheed at runtime.
> Hm... Actually, what I had in mind is nominal subtyping... similar to
> objects, in fact, objects in C++-like languages, just that they have no
> class methods.
Reading the description below, this all looks nice, independently of
the semantics limitation described above. However, you can kiss
farewell to type inference. With such an extensive overloading, you
would need type annotations all over the place.
For the second one,
you can write code that is maximally polymorphic, without too much
fear about the impact of performance (equality is overloaded, so
it still matters...) or strange ambiguity-related error messages.
I believe that "strange ambiguity-related error messages" are the result of stupid programmers, not of the language. If one is careful to design a sane library, most ambiguities never happen! Besides, incorporating whole-program analysis (in the spirit of MLton), one can postpone such errors until the whole application has been written, so for example local ambiguities would be resolved by examining the uses (if a function is always called with arguments of single type, there is no ambiguity).
Not for records, but for objects. From a type-theoretic point of view
they are just equivalent.
By the way, this all looks likes the "used this feature in C++"
syndrome. Sure C++ is incredibly powerful. But it is built on rather
shaky theoretical fundations. So you can't expect to bring everything
from C++ to a new language. Why not think about new ways to solve
problems :-)
Well, I am... but just as you are in your message mentioning the practical impact, so am I. And I think that every way to implement subtyping of records/objects (=named tuples) other than the C++ way has an important practical consequence - it's just slow. I guess that C++ like index-based access is much faster than name-based access neccessary for structural subtyping. Thou, please prove me that I am wrong :) I want structural subtyping, the OCaml way, just very fast.
- Tom