[Haskell-cafe] generate Haskell code from model

Steffen Mazanek haskell at steffen-mazanek.de
Fri Apr 13 14:43:11 EDT 2007

Brian, but don't you think that you have to write a lot
of boilerplate code in Haskell?

Second, if Haskell should be more successful in the
real world there has to be a way of demonstrating
basic ideas of a big program to "customers". How
would you do this? Everybody knows UML class
diagrams, for example. In contrast, nobody knows
about termgraphs or lambda *g*.

Third, assume you already have a model, want to
write the corresponding code yourself?

Thank you very much for contributing to the discussion.
Please assume, that you have to generate the code from
a model. Further assume, that you have no choice and
are not allowed to discuss the sense of this approach :-)
How should the code look like?

Best regards,

2007/4/13, Brian Smith <brianlsmith at gmail.com>:
> On 4/13/07, Steffen Mazanek <haskell at steffen-mazanek.de> wrote:
> >
> > Hello everybody,
> >
> > I would like to start a discussion on how to generate
> > best-practice Haskell code from a model, e.g. from
> > EMF.
> I started learning Haskell precisely to solve problems like this. But,
> once I got into it, I realized that Haskell is a much better modeling
> language than the modeling language I was using (MOF/UML, the predecessors
> to EMF). Furthermore, all the infrastructure built on top of that modeling
> language was very easy to replace with Haskell code. As a result, I gave up
> that effort.
> You said "The benefits of the model+generate approach are well known,"
> however I disagree. W3C DOM, MOF, UML, CORBA, and NetBeans 3.x-4.x are all
> obvious examples of the failure of the model+generate approach. If the
> modeling language is sufficiently powerful, then it should be feasible to
> execute the models directly using a (custom-built) interpreter. If the
> modeling language is weak then it is better to just do the modeling in
> Haskell or another more powerful language.
> The MDA idea was that you would have one model and then be able to use
> that model in a variety of different programming languages, without having
> to rewrite code in each target language. Now, people are getting this
> benefit via a "code, then translate" approach. For example, GWT allows the
> developer to write Java code, then generate the equivalent Javascript,
> without any hand-wavy models in between. JRuby lets one write code in Ruby
> to be used by code in Java; IronPython does the same for other .NET
> languages. In fact, C# is basically the .NET counterpart to EMF.
> FWIW, I also think that data based languages like ERD, Relax NG, and
> XQuery/XPath/XML Schema are a much closer fit to Haskell than EMF. EMF is
> designed to be translated any object-oriented, class-based, (soley)
> subtype-polymorphic, single-dispatched, single-inheritance language; i.e.
> Java. In fact, EMF is really a Java-optimized subset of what was supposed to
> become part of MOF 2.0.
> - Brian

Dipl.-Inform. Steffen Mazanek
Institut für Softwaretechnologie
Fakultät Informatik

Universität der Bundeswehr München
85577 Neubiberg

Tel: +49 (0)89 6004-2505
Fax: +49 (0)89 6004-4447

E-Mail: steffen.mazanek at unibw.de
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20070413/722b23a9/attachment.htm

More information about the Haskell-Cafe mailing list