I added a Scala solution since Haskell is already well represented.<br><br>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.<br>
<br>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:<br>
<br>Courier delivers "let's have lunch" from Susan to Joe<br>Joe replies "Thanks for the message!"<br>Courier delivers "how's your day?" from Joe's Best Friend to Joe<br>Joe replies "Hey Best Friend, thanks for the message!"<br>
Joe's mood changes from "normal" to "happy"<br><br>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. <br>
<br><br><div class="gmail_quote">On Sun, May 27, 2012 at 8:21 PM, Alexander Solla <span dir="ltr"><<a href="mailto:alex.solla@gmail.com" target="_blank">alex.solla@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br><br><div class="gmail_quote"><div class="im">On Sun, May 27, 2012 at 7:07 PM, Richard O'Keefe <span dir="ltr"><<a href="mailto:ok@cs.otago.ac.nz" target="_blank">ok@cs.otago.ac.nz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br>
On 26/05/2012, at 4:16 AM, David Turner wrote:<br>
><br>
> I don't. I think the trouble is that classes don't add value in exercises of this size.<br>
<br>
</div>This was the key point, I think.<br>
In this example, there wasn't any significant behaviour that could be moved<br>
to superclasses. For that matter, whether a supplier is plain, preferred,<br>
or problematic is, one hopes, not a *permanent* property of a supplier.<br>
<br>
Sometimes higher-order functions can substitute for classes.</blockquote><div><br></div></div><div>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.</div>
<div><br></div><div>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:</div><div><br></div><div>-- Library code:</div>
<div>defaultFoo :: Foo</div><div>defaultFoo = Foo { bar = ..., baz = ... }</div><div><br></div><div>-- Client code</div><div>myFoo = defaultFoo { bar = myBar }</div><div><br></div><div>Things can get as complicated as you would like, up to and including inheritance, by using functors other than ((->) a)</div>
<div><br></div><div>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.</div></div>
<br>_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
<br></blockquote></div><br>