[Haskell-cafe] A functional programming solution for Mr and Mrs Hollingberry

Alexander Solla alex.solla at gmail.com
Mon May 28 05:21:47 CEST 2012

On Sun, May 27, 2012 at 7:07 PM, Richard O'Keefe <ok at cs.otago.ac.nz> wrote:

> On 26/05/2012, at 4:16 AM, David Turner wrote:
> >
> > I don't. I think the trouble is that classes don't add value in
> exercises of this size.
> This was the key point, I think.
> In this example, there wasn't any significant behaviour that could be moved
> to superclasses.  For that matter, whether a supplier is plain, preferred,
> or problematic is, one hopes, not a *permanent* property of a supplier.
> Sometimes higher-order functions can substitute for classes.

Functors can always substitute for OO classes.  A class system is a functor
from the set of objects to a set of methods, mediated by inheritance, or
things like message-passing, duck typing, prototyping, etc.

Functions with the type Foo -> Foo can be easily used to implement a
prototype based dispatch mechanism.  Indeed, this is a common Haskell
pattern.  Define:

-- Library code:
defaultFoo :: Foo
defaultFoo = Foo { bar =  ..., baz = ... }

-- Client code
myFoo = defaultFoo { bar = myBar }

Things can get as complicated as you would like, up to and including
inheritance, by using functors other than ((->) a)

The defining characteristic of OO is that objects are stateful, but
self-contained entities.  How methods are defined and dispatched vary
wildly across OO languages.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20120527/63f0afc4/attachment.htm>

More information about the Haskell-Cafe mailing list