Is there a modeling language for the functional programming paradigm?

Question

UML is a standard aimed at the modeling of software which will be written in OO languages, and goes hand in hand with Java. Still, could it possibly be used to model software meant to be written in the functional programming paradigm? Which diagrams would be rendered useful given the embedded visual elements?

Is there a modeling language aimed at functional programming, more specifically Haskell? What tools for putting together diagrams would you recommend?

editted 09/02: What I'm looking for is the most visual, lightest representation of what goes on in the code. Easy to follow diagrams, visual models not necessarily aimed at other programmers. I'll be developing a game in Haskell very soon but because this project is for my graduation conclusion work I need to introduce some sort of formalization of the proposed solution. I was wondering if there is an equivalent to the UML+Java standard, but for Haskell. Should I just stick to storyboards, written descriptions, non-formalized diagrams (some shallow flow-chart-like images), non-formalized use case descriptions?

Answer 1

I believe the modeling language for Haskell is called "math". It's often taught in schools.

Answer 2

Yes, Haskell.

I get the impression that programmers using functional languages don't feel the need to simplify their language of choice away when thinking about their design, which is one (rather glib) way of viewing what UML does for you.

Answer 3

We use theorem provers to do formal modelling (with verification), such as Isabelle or Coq. Sometimes we use domain specific languages (e.g. Cryptol) to do the high level design, before deriving the "low level" Haskell implementation.

Often we just use Haskell as the modelling language, and derive the actual implementation via rewriting.

QuickCheck properties also play a part in the design document, along with type and module decompositions.

Answer 4

I have watched a few video interviews, and read some interviews, with the likes of erik meijer and simon peyton-jones. It seems as when it comes to modelling and understanding ones problem domain, they use type signatures, especially function signatures.

Sequence diagrams (UML) could be related to the composition of functions. A static class diagram (UML) could be related to type signatures.

Answer 5

In Haskell, you model by types.

Just begin with writing your function-, class- and data signatures without any implementation and try to make the types fit. Next step is QuickCheck.

E.g. to model a sort:

class Ord a where
    compare :: a -> a -> Ordering

sort :: Ord a => [a] -> [a]
sort = undefined

then tests

prop_preservesLength l = (length l) == (length $ sort l)
...

and finally the implementation ...

Answer 6

What would be the point in modelling Haskell with Maths? I thought the whole point of Haskell was that it related so closely to Maths that Mathematicians could pick it up and run with it. Why would you translate a language into itself?

When working with another functional programming language (f#) I used diagrams on a white board describing the large blocks and then modelled the system in an OO way using UML, using classes. There was a slight miss match in the building blocks in f# (split the classes up into data structures and functions that acted upon them). But for the understanding from a business perspective it worked a treat. I would add mind that the problem was business/Web oriented and don't know how well the technique would work for something a bit more financial. I think I would probably capture the functions as objects without state and they should fit in nicely.

It all depends on the domain your working in.