[Haskell-cafe] generate Haskell code from model

[Claus Reinke]

>This is true only for programming in the small, isn't it?

my favourite opinion on that subject was expressed, back in 1984, in

    Burstall, Lampson
    A kernel language for modules and abstract data types
    http://www.hpl.hp.com/techreports/Compaq-DEC/SRC-RR-1.html

paraphrasing: programming-in-the-large should look pretty much like
programming-in-the-small. what you need is a simple notation 'for dealing with
big objects (pieces of a program) as if they were small ones (numbers); this is
the basic good trick in matrix algebra'.

meta-mudelling is a popular subject (and my tendency towards puns is not to
be construed as a criticism - i like going meta if i can do so without going crazy;-),
but the pragmatic focus is on the models, isn't it?

try not to think of a modeling language for Haskell code. instead, think of Haskell
itself as a meta-modelling language: first, you design a modelling language suitable for
the problem at hand, then you make that modelling language precise and executable
by prototyping it as an embedded domain-specific language in Haskell, then you
model your problem in that modelling language. finally, you run your model.

sometimes, you are done at this point. sometimes, you will need many more models,
more efficiently implemented, so it makes sense to move from the prototypical
implementation of your modelling language to an efficiency-oriented one (perhaps by
turning an embedded interpreter into an embedded compiler and runtime system).
sometimes, you only needed that one model, but you need it faster, and in a different
language, to fit into some external constraints, so you either make your embedded
compiler generate code in that language, or you re-implement by hand once you
know that your model does what you want. of these, only the last alternative is not
in line with model-driven development, in its code-and-model-are-linked-by-tools
incarnation.

if you need to model parsers, you start with a parser language, if you need to model
other grammar-based problems, such as type systems or operational semantics, you
generalise to monadic combinators, if you need to model financial contracts, you start
with a contract language, if you need to model animation, you start with an animation
language, if you need to model graphical representations of data-flow, you start by
embedding Petri nets, and so on..

it is up to you to find and define the right modelling language for your problem/ 
domain/audience/customers/bosses/.., but Haskell provides good abstractions to
build on, and -not to be underestimated- a common framework (or meta language)
in which several such modelling languages can be combined. the latter not only means
that abstractions common to different modelling languages can be extracted into
libraries, and studied in general (such as monads and monad transformers), it also
means that your model of a grammar can be integrated with your model of an
execution mechanism, which in turn can be linked with your visual model of static
and dynamic properties of your systems. in other words, you can model complex
systems in a single framework, while still getting to choose the most appropriate
language for modelling each part of your system.

>Hmph, how to disprove this argument? Say, you have generated ddl-code
>from an ER-model and now want to generate Haskell data structures that
>operate on this data. How would you procede? This is similar to HaXML
>that helped you to generate Haskell types for an xml schema.

provided that the modelling language is defined precisely, you can write a compiler
for it in Haskell (Haskell is good for writing compilers, remember?-). such a compiler
could generate Haskell code, or tools, or data types, or.., or even Java code. rumour
has it that it could even be used to reverse engineer and process Cobold, if necessary;-)

(the xml example -is that xml schemata or dtds, btw?- demonstrates that precise
definitions don't necessarily make for concise code, but thats what you get with
standards..)

claus

which reminds me that so far there have been only two times i found myself agreeing
with anything umlish: a paper by Harel explaining his ideas about statecharts, and a
workshop of umlers i stumbled into, where it became clear to me that those pragmatic
users of uml mainly use the graphics to depict their type hierarchies, while tending to
ignore the advanced, complicated, and not necessarily well-defined aspects of uml.