[Haskell-cafe] Need ideas how to model the lack of something

martin martin.drautzburg at web.de
Tue Dec 15 09:25:41 UTC 2015


Am 12/15/2015 um 08:33 AM schrieb Joachim Durchholz:

>> On 14 December 2015 at 17:28, Joachim Durchholz <jo at durchholz.org> wrote:
>>> Mmm... this is the second time this has been raised.
>>> What's the problem with OOP style? Something specific with Haskell,
>>> something about OOP in general, something else?

> 
> P.S.: I'm not trying to criticize anything, just trying to understand what the issue is.
> Is there a webpage like "Haskell for OO-warped minds" that explains how to transition one's idioms? I have a good grasp
> of Haskell in-the-small, but I haven't had an opportunity to learn the larger-scale issues, so I'm probably just being
> dense and would like to change that.

I'd be interested in that "Haskell for OO-warped minds" too.

As for my specific question, here's what I believe I've learned.

Abstract classes or interfaces are commonplace in the OO world. But even there you have to provide a concrete
implementation eventually. While you can program in a similar style in haskell by using typeclasses, haskellers tend to
start with a concrete implementation and then use typeclasses to express commonalities of concrete implementations.

While some data types, particularly those which wrap functions (the simplest of which is probably the state monad), look
like they are providing an abstract interface to a computation, they are actually concrete things. Or take the List data
type: it is not just something you can prepend an element to, express an empty list and split it into head and tail, but
really a concrete thing, which allows implementing these operations. You could implement these three operations (:,
head, tail) and the constant [] on top of other data structures, but this would not make them a List.

Some time ago I asked the question, whether you have a choice between using a newtype/data or a typeclass and if so
which is the preferred approach. The answer was yes, these two concepts can occasionally replace each other and "short
answer: use data". This was one reason why I didn't even try to use a typeclass in my problem here. Now I believe that I
misread "short answer: use data" as using the "data" keyword. What it really meant is: "be concrete".



More information about the Haskell-Cafe mailing list