Matthias-Christian Ott wrote:
Hi, usually I'm sceptical of programming languages which are not based on the von Neumann architecture, but recently I got interested in functional programming languages.
The arrogance of lots of Haskell users, who made me feel that using a programming language other than Haskell is a waste of time, combined with vanguard mathematical notation has been very attractive to me and I have decided to get at least an idea of Haskell and its concepts.
Some weeks ago I learned programming in Dylan and was impressed by its object system which is basically a stripped version of CLOS. Multiple dispatch together with a well-thought-out object system is quite powerful, because it removes the burden of including methods in the class definition.
At the moment I'm reading the "Functional Programming using Standard ML" and I'm in the chapter on data types.
This afternoon it occurred to me that classes and data types are symmetric. In a class hierarchy you start an abstract super class (the most abstract is the class object in some languages) and further specialise them via inheritance; with data types you can start with specialized versions and abstract them via constructors (I'm not sure how message sending to a superclass looks like in this analogy).
Anyhow, I also came across an interesting presentation. Andreas Löh and Ralf Hinze state in their presentation "Open data types and open functions" [1]:
* OO languages support extension of data, but not of functionality. * FP languages support extension of functionality, but not of data.
Their first point refers to the fact that in most object-oriented languages don't allow the separate definition of classes and their respective methods. So to add new functions, you have edit the class definitions.
However, in functional programming languages you can easily add new functionality via pattern matching, but have to either introduce new types or new constructors, which again means to modify existing code.
In Dylan (and in Common Lisp) you define methods separate from classes and have pattern matching based on types. This solves all mentioned problems.
So my question is, how are algebraic data types in Haskell superior to CLOS (despite the fact that CLOS is impure)? How do both compare?
What has Haskell to provide what Common Lisp and Dylan haven't?
Thanks!
Regards, Matthias-Christian
Type classes. Mike