[Haskell-cafe] Re: FP design

[apfelmus]

Thomas Schilling wrote:
> Levi Stephen wrote:
>>
>> I'm was wondering how most people work during when designing a functional 
>> program. Do you create data structures/types first? Do you work from some type 
>> signatures?
> 
> But there's a third thing that you can
> do, other than start implementing:  think about the laws/properties that
> should hold.  That's not always simple, in fact, it rarely is.

Yes, the classic approach: systematically derive programs from their 
specification. The classic paper on that is

   Paul Hudak. The Design of a Pretty-printing Library.
   http://citeseer.ist.psu.edu/hughes95design.html

with a follow-up

   Philip Wadler. A prettier printer.
   http://decenturl.com/homepages.inf.ed/wadler-98-prettier-printer

The man who derives all his programs from specification is Richard
Bird. You may want to have a look at his recent sudoku solver

   Richard Bird. A program to solve Sudoku.
   Slides: http://icfp06.cs.uchicago.edu/bird-talk.pdf

where he starts with an apparently correct but hopelessly slow
specification and transforms it into a blazingly fast one. His
introduction to Haskell

   Richard Bird.
   Introduction to Functional Programming using Haskel (2nd edition).
   http://decenturl.com/amazon/bird-introduction-functional

emphasizes the classic style, too.

You may think "this is all nice, but my problem is too 'soft' for 
mathematical laws and properties and such". Well, if you don't search, 
you won't find. Here's an example for a "soft" problem domain:

   Simon Peyton Jones, Jean-Marc Eber, Julian Seward.
   Composing contracts: an adventure in financial engineering.
   http://decenturl.com/research.microsoft/spj-financial-contracts

Of course, the laws "of nature" governing your problem domain may be 
hard to find, so it may be worth to "just implement" and let some "law 
intuition" guide you. Well-known example: darcs.


Regards,
apfelmus