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

[Eric Rasmussen]

I added a Scala solution since Haskell is already well represented.

Regarding exercises that are easier in OO, I don't think you'll find one
that a good Haskell programmer can't match in a functional style. But if
you make simulation the goal of the exercise (rather than writing a program
that takes input and produces the correct output however it likes), you'll
get a nice compare/contrast of OO and non-OO approaches.

One idea (contrived and silly though it is) is modeling a Courier that
delivers message to Persons. There is a standard default reply for all
Persons, some individuals have their own default reply, and there are
conditional replies based on the sender. Each reply has the ability to
alter a Person's mood. The goal of the exercise would be to read in a CSV
file in the form of "To, From, Message", and then output the interactions
based on rules. A sample run might look like:

Courier delivers "let's have lunch" from Susan to Joe
Joe replies "Thanks for the message!"
Courier delivers "how's your day?" from Joe's Best Friend to Joe
Joe replies "Hey Best Friend, thanks for the message!"
Joe's mood changes from "normal" to "happy"

This would be a trivial exercise for any OO programmer, and I suspect
solutions in different OO languages would look pretty much the same. But in
pure functional programming there are more choices to make (particularly
the choice of data structures and types), so you might see a wider range of
creative approaches.


On Sun, May 27, 2012 at 8:21 PM, Alexander Solla <alex.solla at gmail.com>wrote:

>
>
> 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.
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20120529/4268fe34/attachment.htm>