Jan-Willem Maessen wrote:

On Jun 22, 2005, at 9:38 PM, Andrew Ward wrote:

...

Pal-Kristian Engstad wrote:

...

On Wednesday 22 June 2005 05:38 pm, Andrew Ward wrote:

...

What would be the normal way for a Haskell programmer to handle the typical shape example in beginner OO tutorials?

By not doing OO. You have to ask yourself, what is the purpose and/or benefit of using OO? In C++, OO is _useful_ because you restrict the problems of mutable data (by enclosing it in C++ classes).

ML type languages have other methods of doing things, and guess what, OO is not that needed for these languages. Sum-types, pattern-matching and data constructors make half of the need for OO go away. Higher order functions and make it even less needed. For the rest, there's always work-arounds.

PKE.

To handle the problem of drawing all shapes, in c++, I would have a list of shape pointers:

struct shape{ virtual void draw(...);}; struct circle : public shape {...}; struct square : public shape {...}; std::list shapes; for(std::list::iterator it = shapes.begin();it != shapes.end();++it) { (*it)->draw(...); }

This general pattern of dynamic binding I use over and over again. Could you give me some example code of this type of thing handled in Haskell's way? Assuming that the number of classes deriving from shape might get quite large.

It seems to me that if this is the specific problem being addressed, a list of higher-order functions is exactly the right solution in any ML-like language, and this is why there have been several responses to that effect.

I do think it's fair to say "consider changing the way you think" to OO programmers trying to learn Haskell. If we were on an OOP mailing list, I could ask for days how to simulate pattern matching and algebraic types---and get a nonsensical runaround involving the visitor pattern and huge swaths of unreadable code.

Ralf, I think it's incumbent on you, having said several times "that isn't solving the problem", to more clearly explain what problem you think exists and cannot be solved gracefully (I suspect it has to do with extensible down-casting---which is indeed hard in Haskell, but many reasonable people might consider irrelevant or even overtly bad).

Andrew, if this isn't the problem you're actually trying to solve, can you explain why a simple list of functions doesn't help you?

I think I will need to learn a little more Haskell before I can appreciate all the different responses. However I will try to answer your question. Assuming I have a list of shapes somewhere in my program. The list would be heterogeneous, or at least contain data constructed using various different type constructors. The list would also be changing all the time, for example in a drawing program. So, using the suggestion of a list of drawing functions, would this not mean I would have to alter the list of drawing functions each time I alter the list of shapes? It does not seem an extensible solution. When it comes to adding new types or new functionality for existing types would it not be easy to miss updating a part of the program source that needed updating? The example I have found the simplest is the one given by Lennart, however this to me seems equivalent to the way people use switch statements in C to mimic dynamic binding. As I said before, I will have to learn more haskell and investigate OOHaskell properly. Thanks for all your responses.

-Jan-Willem Maessen

...

Andrew Ward.

_______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell