On 11/5/07, Levi Stephen wrote:

Hi,

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?

For example, take a blog. Is the first step likely to be something like:

data BlogEntry = BlogEntry { title::String,content::String,comments::[Comment] } type Blog = [BlogEntry]

or more likely thinking about what functions will be required:

addEntry :: BlogEntry -> Blog -> Blog displayBlog :: Blog -> HTML displayEntry :: BlogEntry -> HTML

I don't know how you can do one without the other. I would probably start in a case like this by writing down a few basic types, then trying to start to write down the function type signatures, which will probably point to more types that need to be defined, iterating until I reach a fixed point. I can't write type signatures unless I know what the types are. But I don't know what the types should look like unless I know what the interface should look like, either. One thing that's for sure, though -- I always write type signatures for top-level definitions. I can't think straight unless I write the type signature before writing the code. Cheers, Tim -- Tim Chevalier * catamorphism.org * Often in error, never in doubt "Thus spake the Master Programmer: When you have learned to snatch the error code from the trap frame, it will be time for you to leave."--J. Geoffrey

Levi Stephen wrote:

Hi,

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?

In *any* programming language, my workflow usually goes like this: 1. Think about it for a minute or two. Try to decide on good abstractions. 2. Start programming it. 3. Realise that my chosen system of abstractions is fundamentally flawed. 4. Delete source code. 5. Think some more. 6. Start coding again using new plan. 7. Iterate as required. I'm not sure whether you can properly call that "design" though... more like "iterative prototyping". ;-) It used to be easier with OOP. I'm still not quite sure how to pick the best possible abstractions in an FP context...

On Tue, 2007-11-06 at 10:32 +1030, Levi Stephen wrote:

Hi,

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?

As others have mentioned: both. 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. But it helps you get one step closer to what you need to implement. If you can find useful properties, though, you get lots of test-cases for free by formulating and testing them using QuickCheck. Then, when implementing, you probably realize that you might need some more combinators. I usually then stop and implement the combinator first, test it and continue. Some other guidelines I recommend: * Try not to be too abstract in the first place. Try implementing a specialized version first, and then see how you can abstract it, once you implemented all facets. Sometimes, you need to add some instance constraints, but the compiler will tell you where. * Test early and often. Note that in Haskell you can get the compiler to typecheck successfully by adding dummy-definitions using "_" and "undefined". E.g.: foo :: A -> B -> C foo _ _ = undefined * Define abstract types, or at least type synonyms. It's so easy to define new abstract types in Haskell, that you should do it often. This makes it much easier to later choose the proper data structure, once you know what details you need. Also, it's implicit documentation, compare type Author = String; type Title = String addPost :: Author -> Title -> String -> Blog -> Blog and addPost :: String -> String -> String -> Blog -> Blog * Think about complexity of your primitives. This is hard to fix later, so it should be taken into account early on. Of course, there's sometimes a fine line between mature and premature optimizations. * As Don often says, try to keep things pure wherever possible. It will make your code so much more compositional, easier to test and correct. There's more, but I'll stop here for now...