<span class="q">Brian, but don&#39;t you think that you have to write a lot<br>of boilerplate code in Haskell?<br><br>Second, if Haskell should be more successful in the<br>real world there has to be a way of demonstrating
<br>basic ideas of a big program to &quot;customers&quot;. How
<br>would you do this? Everybody knows UML class<br>diagrams, for example. In contrast, nobody knows<br>about termgraphs or lambda *g*.<br><br>Third, assume you already have a model, want to<br>write the corresponding code yourself?
<br><br>Thank you very much for contributing to the discussion. <br>Please assume, that you have to generate the code from <br>a model. Further assume, that you have no choice and <br>are not allowed to discuss the sense of this approach :-) 
<br>How should the code look like?<br><br><br>Best regards,<br>Steffen</span><br><br><div><span class="gmail_quote">2007/4/13, Brian Smith &lt;<a href="mailto:brianlsmith@gmail.com">brianlsmith@gmail.com</a>&gt;:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<span class="q">On 4/13/07, <b class="gmail_sendername">Steffen Mazanek</b> &lt;<a href="mailto:haskell@steffen-mazanek.de" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">haskell@steffen-mazanek.de
</a>&gt; wrote:</span><div><span class="q"><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hello everybody,<br><br>I would like to start a discussion on how to generate <br>best-practice Haskell code from a model, e.g. from<br>EMF.</blockquote></span><div><br><br>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.
<br><br>
You said &quot;The benefits of the model+generate approach are well known,&quot;
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.<br><br>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 &quot;code, then translate&quot; 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.
<br><br>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.<br><br>- Brian<br><br></div></div>
</blockquote></div><br><br clear="all"><br>-- <br>Dipl.-Inform. Steffen Mazanek<br>Institut für Softwaretechnologie<br>Fakultät Informatik<br><br>Universität der Bundeswehr München<br>85577 Neubiberg<br><br>Tel: +49 (0)89 6004-2505
<br>Fax: +49 (0)89 6004-4447<br><br>E-Mail: <a href="mailto:steffen.mazanek@unibw.de">steffen.mazanek@unibw.de</a>