[Haskell] Dynamic binding

[Jan-Willem Maessen]

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<shape *> shapes;
> for(std::list<shape *>::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?

-Jan-Willem Maessen


> Andrew Ward.
>
>
> _______________________________________________
> Haskell mailing list
> Haskell at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell