[Haskell-cafe] C++ class = neutered (haskell class + haskell existential)

Gabriel Dos Reis gdr at integrable-solutions.net
Sun Aug 20 09:31:01 EDT 2006


Bulat Ziganshin <bulat.ziganshin at gmail.com> writes:

| Hello Gabriel,
| 
| Sunday, August 20, 2006, 8:26:30 AM, you wrote:
| 
| > | There is a major difference though, in C++ (or java, or sather, or c#,
| > | etc..) the dictionary is always attached to the value, the actual class
| > | data type you pass around.
| 
| > The dictionary can be attached to the operations (not just to the values) by
| > using objects local to functions (which sort of matierialize the
| > dictionary).
| 
| This means that type classes can be _emulated_ in C++. but the bare
| semantics is just as we said - in Haskell dictionaries are passed
| around the functions (unless existential used) and in C++ they are
| attached to objects
| 
| i agree that emulation you provided is closer to type classes at least
| in that it implements _dynamic_ dispatching vs compile-time
| dispatching of templates. but typical C++ programming involves using
| classes and templates, not the unusual technique you have introduced.

Who knows what "typical C++ programming" is?

I don't think what I showed is unusual.  As a matter of fact, it is just
a dynamic version of trait techniques (which as I understood inspired
AT for Haskell).  I don't think I invented anything new or unusual here.
I most certainly have seen similar techniques in production codes
years ago.  You should not dismiss it as unusual because you might not
be familiar with it.  

As for the comparison with function to pointers, well it is a familiar
argument: just because we had function to pointer means we could not have 
virtual functions :-)  As a matter of fact, virtual functions provide
invariants that are hard or impossible to attain with pointers to
functions.  Similarly, I would find it more useful to see an analysis
of invariants type classes provide (to support programming
techniques) that are hard or impossible to attain with mere
parameterized classes, than surface comparison of language features.

My opinion is that comparison of language feature for language
language is often a hard and meaningless exercise.  I find it more
interesting to focus of programming *techniques* supported by language
features.  Such a comparison usually does not need exact
correspondence of feature for feature.  No doubt, this is not an easy
exercise either. 


More information about the Haskell-Cafe mailing list