Modelling languages for FP (like UML for OO)
Hi all In object-oriented programming, UML is used to model programs. In functional programming (especially Haskell) we use ??? The only graphical modellering language I have found is FAD: http://www.cs.kent.ac.uk/pubs/2001/1152/ . Are there other approaches? Are anybody, except for the creates of FAD, using it? If you are using FAD, what are your experiences with it? I am mainly interested in the macro level. That is modules, classes, class instances, ... Not in modellering the internals of a function. Greetings, Mads Lindstrøm
On Thu, 19 Jan 2006, Mads [ISO-8859-1] Lindstrøm wrote:
Hi all
In object-oriented programming, UML is used to model programs. In functional programming (especially Haskell) we use ???
Haskell :-)
I am mainly interested in the macro level. That is modules, classes, class instances, ... Not in modellering the internals of a function.
I tend to just write the equivalent haskell code with the function definitions left out. I suspect the only thing that can really be gained with a more graphical language is drawing dependancy lines between modules and the like - though I was never big on the formalised modelling languages in the first place, so I may not be the best person to conclude that. -- flippa@flippac.org Sometimes you gotta fight fire with fire. Most of the time you just get burnt worse though.
Mads Lindstrøm wrote:
In object-oriented programming, UML is used to model programs. In functional programming (especially Haskell) we use ???
Nice question. The problem with UML class diagrams is that they are only really suited to "classical" OO (composition and inheritance) and thus are missing some important features: a) the UML notation for generics (type parameters) is somewhat ad-hoc, e. g. there is no good visible disctinction between a template and its instantiation. b) UML supports interfaces, but (speaking Haskell) they are all unary predicates (a type implements an interface) and there is no notation for multi parameter type classes (would need a hypergraph instead of a graph :-) -- -- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 -- ---- http://www.imn.htwk-leipzig.de/~waldmann/ -------
On Thursday 19 January 2006 14:09, Mads Lindstrøm wrote:
In object-oriented programming, UML is used to model programs. In functional programming (especially Haskell) we use ???
However, not everyone in the OO camp thinks that UML is really useful: http://archive.eiffel.com/doc/manuals/technology/bmarticles/uml/page.html Ben
G'day all. Quoting Benjamin Franksen <benjamin.franksen@bessy.de>:
However, not everyone in the OO camp thinks that UML is really useful:
http://archive.eiffel.com/doc/manuals/technology/bmarticles/uml/page.html
Having actually used it (once), the consensus seems to be: 1. It only applies to a "pure" OO style. Just about all useful programming languages for programming-in-the-large (Haskell included) are multi-paradigm. 2. It's difficult to refactor. This makes it useless for design purposes, especially if your development development methodology is sufficiently agile. The upshot is that UML's only use is for docmentation after the fact, or for Big Design Up Front projects. But only if you use a strict subset of what most programming languages give you. The most notable exception to this rule is Java. Java really only provides objects as an abstraction mechanism, so UML is a good fit. On the topic of Haskell, I've found that traditional dataflow modelling techniques (dataflow diagrams, JSD etc) can model lazy code pretty well. But, once again, we're talking about a subset of what the language provides. Lambda is also the ultimate imperative, after all. Cheers, Andrew Bromage
<ajb@spamcop.net> wrote in message news:20060119185325.iw9di8gwcc0kkkgw@webmail.spamcop.net...
G'day all.
Quoting Benjamin Franksen <benjamin.franksen@bessy.de>:
However, not everyone in the OO camp thinks that UML is really useful:
http://archive.eiffel.com/doc/manuals/technology/bmarticles/uml/page.html
Having actually used it (once), the consensus seems to be:
1. It only applies to a "pure" OO style. Just about all useful programming languages for programming-in-the-large (Haskell included) are multi-paradigm.
2. It's difficult to refactor. This makes it useless for design purposes, especially if your development development methodology is sufficiently agile.
The upshot is that UML's only use is for docmentation after the fact, or for Big Design Up Front projects. But only if you use a strict subset of what most programming languages give you. I am no rabid UML fan, but I am reasonably familiar with it, and I have to say this is garbage. UML class diagrams are invaluable both for the conceptual analysis and design work as well as for after the fact overview of the class structure. State models are essential for designing the behavior of interesting objects. Slightly less important (IMHO) but still useful are acitivity charts (for use case flow), and interaction diagrams (although I have found them personally less useful for the initial conceptualization. I have found them more useful for explaining method interactions to someone). The fact that highly popular tools like TogetherJ put a lot of effort into recovering the class diagram and the interaction diagram from code should be some indication of their importance and usefulness. In addition, the latest MDA model compilers can generate entire applications from UML models. Some documentation that is!
I have personally noticed less of a need for modeling tools with Haskell b/c the language itself is fairly abstract, but also because i tend not to write stateful, structurally rich applications in Haskell. If the next version of Haskell does support a more convenient and extensible datatype mechanism, then i can see people using Haskell for such applications and therefore a need for some kind of diagrammatic modeling tool there too. cheers -s
Hello Srinivas, Sunday, January 22, 2006, 2:20:32 AM, you wrote: SN> stateful, structurally rich applications in Haskell. If the next version of SN> Haskell does support a more convenient and extensible datatype mechanism, i am inetersting - what you mean by "more convenient and extensible datatype mechanism"? i also not fully satisfied by current one, even with hugs/ghc extensions, so i'm interested in thoughts about improvements in this area -- Best regards, Bulat mailto:bulatz@HotPOP.com
"Bulat Ziganshin" <bulatz@HotPOP.com> wrote in message news:73-1823664531.20060122133738@HotPOP.com...
Hello Srinivas,
Sunday, January 22, 2006, 2:20:32 AM, you wrote:
SN> stateful, structurally rich applications in Haskell. If the next version of SN> Haskell does support a more convenient and extensible datatype mechanism,
i am inetersting - what you mean by "more convenient and extensible datatype mechanism"? i also not fully satisfied by current one, even with hugs/ghc extensions, so i'm interested in thoughts about improvements in this area Mostly the stuff that has been discussed recently. For example requiring unique field names across all datatypes, the lack of support for width and depth subtyping, mutually referencing datatypes are awkward to do without resorting to the ST and STRef monads (not standard), which introduces complications of its own, like have to introduce composition if you're "in" some other monad like IO. I know some of this is handled by T-Rex, but i would like to see it become standard
cheers
-- Best regards, Bulat mailto:bulatz@HotPOP.com
participants (7)
-
ajb＠spamcop.net -
Benjamin Franksen -
Bulat Ziganshin -
Johannes Waldmann -
Mads Lindstrøm -
Philippa Cowderoy -
Srinivas Nedunuri