[Haskell-cafe] generate Haskell code from model

Neil Mitchell ndmitchell at gmail.com
Wed May 9 15:21:48 EDT 2007


Hi Steffen,

It sounds a lot to me like:

* Create a visual meta-language
* Program with diagrams
* Translate to Haskell

If thats the case, how is "Translate to Haskell" different from
"Translate to C++"? It only makes a difference if you go in and edit
the result, but then you've lost your model?

The other thing is that defining a domain specific language is well
understood in Haskell, and generally looks quite nice. The advantage
is that it can integrate with the rest of Haskell easily - if you take
away the Haskell and move into the realm of models I don't see how you
can keep this selling point.

(Personal note: I detest modelling languages with a passion, and I
love Haskell with a passion - I'm curious whether I love or hate the
combination)

Thanks

Neil


On 5/9/07, Steffen Mazanek <haskell at steffen-mazanek.de> wrote:
> I have done some experiments relating to our discussion. The approach to
> generate Haskell code from UML class diagrams is not very promising. However
> one may define a visual notation of Haskell (this is no new idea of course),
> provide better tool support (in particular editor+code generator) and pull
> the Haskellers away from vim, emacs or even from the Visual Studio Plugin
> "Visual Haskell", that is more a Haskell IDE Integration than a visual
> programming environment (great work either way!).
>
> I have described a possible toolchain towards a real Visual Haskell at my
> blog:
>
> http://www.steffen-mazanek.de/blog/2007/05/visual-language-howto.html
>
> Best regards,
> Steffen
>
> 2007/4/14, Brian Smith <brianlsmith at gmail.com>:
> > On 4/14/07, Steffen Mazanek <steffen.mazanek at googlemail.com > wrote:
> >
> > > Brian, but don't you think that you have to write a lot
> > > of boilerplate code in Haskell?
> >
> >
> > I have never felt I was writing a lot of boilerplate. There are a lot of
> abstraction mechanisms in Haskell to avoid boilerplate.
> >
> >
> > > 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*.
> >
> >
> > I've never had to show a UML or ER diagram to any business people--usually
> they want a slideshow that is far simpler and a little prettier. The fact
> that "nobody knows about termgraphs or lambda"  in your group means that you
> probably shouldn't be considering Haskell (for the same reason my bosses
> always asked me to document everything--"in case you get hit by a bus").
> >
> >
> > > 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?
> >
> >
> > I am not sure if you are trying to solve a real problem or not. If you are
> solving a real problem, where you already happen to have an EMF model which
> you are required to generate code from, then I recommend to just do
> everything in Java using the existing tools built for EMF.
> >
> > If you decide to still keep working in Haskell, and it works out well,
> please share your solution because I think many people here will be very
> interested. wxHaskell, OOHaskell, and O'Haskell are all starting points for
> this type of project.
> >
> > - 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
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>


More information about the Haskell-Cafe mailing list