[Haskell-cafe] generate Haskell code from model

Fri May 11 00:08:15 EDT 2007

Hi Neil,

It sounds a lot to me like:
>
> * Create a visual meta-language
> * Program with diagrams
> * Translate to Haskell

Yes, that is true and I guess this is a standard procedure, isn't it?
The translation process is not at all different from your "Translate to
C++". The difference is the Visual Language. It is hard to understand
a program just by reading the code. An easy to understand visual notation
can ease the understandability of your programs. Nowadays there
are so many tools out there, that it is very easy to implement such
a visual language.
A decade ago there already was research in this direction, however,
it was pretty "make a good tool"-oriented. Today we could tackle the
visual notation with all forces and get the tool support for free (nearly).

For example, the notion of a package diagram is for Haskell as
useful as for OOP languages, because it can help you to understand
the overall structure of a program. On a deeper level you could plug
together a visual language for type class hierarchies (similar to but of
course not equivalent to class diagrams), a "type-construction-language"
and what else comes to your mind and get a Haskell CASE tool.

The problem of modeling+editing is nearly solved in the OOP world
(see FUJABA for instance or EMFs JMerge). openArchitectureWare
lets you define protected regions for this purpose - a very general
approach that is not so good for readability.

You say Haskell is good for implementing DSLs, yeah, than it will
be no problem to define a DSL for itself :-)

Ciao,
Steffen

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
> >
> >
>

-- 
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/20070511/a50f1eee/attachment.htm