What's the problem that is actually trying to be solved? The user of your implementation will inform the design choices you make.

Using functions to represent objects like this is rather silly because they are opaque and only support a single operation.

Here are a number of possibly better ways to do it:

  - Emulate objects with functions and messages like with scheme or lisp.

  - Use structural typing or polymorphic variants like in OCaml.

  - Use records with function fields.

  - Use a variant union.

  - Extend/build a list monad over your class.

Can you think of other or better ways?

The OO approach would be to have a virtual function in the parent class and then use lists of the parent class type. Does Haskell prevent that from working, or is he just attacking the OO approach based on a bad OO design?

I'd argue that he's using a bad FP approach. He focuses on one aspect of shapes: testing whether a point is inside it or not. But this is far from a complete, usable representation. How do you draw a shape? Find its edge? Find its bounds? Convex hull? Transform? Test for convexity?

Basically, the original post is just another newbie FP realising that - hey - if you're only every going to call one function of a class then the class is completely defined by that function. He presents a poor and incomplete solution.

There are much better blog posts on FP design than this. Please don't upvote this one.

Haskell types do not have an inheritance structure. Typeclasses do, however this still does not allow you to create a heterogeneous list. This is probably a bit terse, but you'd really be better off to go read an introduction to the Haskell type system than to have me try to explain it here.

The OO approach is possible in Haskell using "existential types". However, this is an extension to the language which is rarely used.

The more normal solution is to make a single data type which is a disjunction of all the shapes which you want to deal with.