on Sun Jun 24 2012, Pyry Jahkola <pyry.jahkola-AT-iki.fi> wrote:
More importantly, I'm still kind of missing the point of why the feature of operator overloading is really needed. In essence: How should binary operators behave? Steven's TypeErasure defines binary operators such that only when the wrapped types of a and b are the same, can you sum them up: "a + b".
But where would you use this kind of an "any", where only some of the instances can be added up, and others cause undefined behavior? Wouldn't you actually do the addition on the side where you know the types, and not on the type-erased side?
Do we really have a real world use case that would prompt us to implement features like operator overloading?
Well, it's interesting; this type erasure can be viewed/used two different ways: 1. Runtime polymorphism 2. Static polymorphism with separate compilation of generic functions Approach 1 admits a runtime type error when the types don't match in a+b. Approach 2 doesn't. Haskell actually takes approach 2. Prelude> :t (+) (+) :: (Num a) => a -> a -> a That's why, for example, it isn't possible to make a list of a given type class and store two different types that conform to that type class in the list. *Your* type erased things do runtime polymorphism, so they're very different from Haskell's typeclasses in that sense. For dynamic polymorphism in Haskell, you need something like http://hackage.haskell.org/trac/ghc/wiki/PolymorphicDynamic
Before releasing more worms from the can of type-erased operators, I must confess that I know still too little about the possible uses for type erasure / expression problem / what you name it. What I propose is we should look into how e.g. Haskell and Clojure programmers use their type classes and protocols.
It's probably a good idea to learn as much as possible from other languages, but that said, we *do* have plenty of prior art in C++ for type erasure. Just making those use cases better is a worthy goal on its own. -- Dave Abrahams BoostPro Computing http://www.boostpro.com