[Haskell-cafe] generate Haskell code from model
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?
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
> 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
Universität der Bundeswehr München
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...
More information about the Haskell-Cafe