Neuer Blog: Visual Languages

Ich habe einen neuen Blog gestartet, der für die tägliche Dosis an visuellen Sprachen sorgen soll: visual-languages.blogspot.com.

AGTIVE 2007

I am just back from AGTIVE 2007 in Kassel. As expected there have been a lot of interesting people with interesting projects. I add more impressions in the comments soon, but I first have to organize all that stuff...

Haskell Workshop 2007

On September, 30th I have been at the Haskell Workshop (also in Freiburg). Lots of interesting talks! In particular I enjoyed the talks about Program Coverage (Andy Gill), Boilerplate Removal (Neil Mitchell) and the presentation of xmonad (Don Stewart).

Back from Andalusia

Vom 25.08.-09.09.07 waren wir in Andalusien, allerdings habe ich es leider erst jetzt geschafft, ein paar ausgewählte Fotos für die Weltöffentlichkeit zusammenzustellen... Stationen unserer Reise ware unter anderem Granada, Ronda, Gibraltar, Marbella und Malaga. Enjoy!

IFL 2007 - Day 2

Today only three sessions took place due to the excursion (a nice visit of Geldermann-Sektkellerei...). The first was about contracts, the second about Algorithms and Data Structures and the last one about Foundations. My talk was part of the second session, you can download it here: Graph Parser Combinators

My key learnings have been:

• Malcolm Wallace: polyparse, commit is the principle dual to try known from parsec, parsing can be done lazily

After my talk I got several advices:

• Why are (graph) parser combinators so powerful? They are aware of a context! Thus they are more powerful than general-purpose parsers for context-free languages. Thank you Malcolm for pointing this out!


• I have to try to generalize my approach such that it is usable for a broader range of problems (advice by Frank Huch).


• I should try not to pass the active node that much but instead should really try to hide it within the monad.


• A parser type should not depend on lists of tokens. I learned that Malcolm already abstracted from lists in a current version of polyparse (via type classes).

IFL 2007 - Day 1

Today four different sessions took place at IFL'07: Compilation I, Applications I, Parallelism I and Types I. Some comments and learnings below:

• Jeroen Fokker: Essential Haskell Compiler, a talk about constructing a fully-fledged Haskell compiler in a very modular manner using a chain of transformations and generative technologies, nice for teaching, because modules are very specialized and concise, easy to add transformations


• Neil Mitchell: Supero, shows how to boost the runtime-performance of Haskell programs, Haskell programs can perform nearly as good as C programs although they are formulated on a far higher level


• Rinus Plasmeijer: i-Tasks, a library to compose workflows automatically providing the corresponding web interface, remembers me a little bit to the Synthesizer Generator of Reps and Teitelbaum that derives structured editors from data types or the Editor Combinators of Kahl et al.

People here are very nice so I am looking forward to my talk tomorrow!

IFL 2007

I want to invite you to watch my talk at IFL 2007. It will take place at September 28, 2007 and its about Graph Parser Combinators, one of my current research projects.

See you in Freiburg!

Linie mit Knickpunkten

Wo nur liegt die ästhetische Mitte einer Linie mit Knickpunkten (also einer Zickzacklinie). Solch eine Linie besteht aus mehreren hintereinanderfolgenden Segmenten. Es gibt derart viele in Frage kommende Punkte, z.B.

• Mitte des Pfades, also exakte Mitte der Gesamtstrecke


• Mitte des mittleren Segments, bzw. wenn nicht vorhanden mittlerer Knickpunkt


• Mitte des Segments, in dem die Mitte des Pfades liegt


• Schnittpunkt mit Mittelsenkrechter der Strecke zwischen den beiden Endpunkten


• nächstliegender Punkt auf der Linie zum Mittelpunkt der Endpunkte


• Mitte des nächstliegenden Segmentes


• ...

Aber wo ist denn nun die ästhetische Mitte? Ich stelle demnächst hier mal Screenshots ein und lasse abstimmen :-)

Konkret geht es übrigens um eine UML-Assoziation mit Knickpunkten. Nun soll ein Label mit dem Namen der Assoziation möglichst hübsch positioniert werden...

Visual Language Howto

In this post I describe a possible toolchain that lets you define your own visual language in an instant.

To make things less abstract I use Visual Haskell as an example. The idea of a visual notion of Haskell was first (to my knowledge) introduced in the paper Visual Haskell: A First Attempt by John Reekie.

To get an impression of the following steps have a look at the image below:



Now I explain the steps shortly:

• Define the metamodel: As a very first step you have to define your metamodel, i.e. the language constructs of your visual language. In UML you have packages and classes for example. So before you can define Visual Haskell you first have to decide how deep you want to model the language. For simplicity and clarity we just model the concepts Package (=Directory), Module, Function and TypeDecl. We use the Eclipse Modeling Framework and Ecore as a metametamodel. The standard tree editor provided by EMF is enough to define the needed EClasses. The result of this first step is the file haskell.ecore, our metamodel.


• Specify and generate the editor: This step is not really needed to proceed, because EMF provides a simple tree editor for your metamodel for free. However, we want a Visual Haskell and a tree editor may not be visual enough... Nowadays nobody programs such a simple diagram editor by hand. Instead there are nice diagram editor generators out there, for example DiaMeta or the Eclipse Graphical Modeling Framework. I prefer DiaMeta because it is a product of my university department :-) and it supports syntax-directed as well as free-hand editing.


• Edit a model: The result of this step is a xmi-file that corresponds to the previously defined metamodel. We provide a short Data.xmi just to give you an impression.


• Generate code: UML is so widely used, because it is possible to generate a lot of code from the model. And for sure nobody would model Haskell if she had to write the code represented by the model herself. Thank God, there is a nice framework that supports you in writing your code generator: openArchitectureWare. All you have to do is to install the framework, define a workflow and some templates and you are done. The templates are defined in a language called xpand that is very easy to use and that provides support for file creation, modularization of templates, protected regions (very important if you want to regenerate the code after manual changes) and so on. We provide an example workflow and a template for modules.

That's it! We are done already.

Note, that the described toolchain is just an example. And it worked for me quite well. Nevertheless, you should have a look at the many other tools out there, that provide similar functionality and may be even better suited for your purpose.

I hope that you now are motivated and qualified to try some ((meta)meta)modeling on your own. Feel free to post questions or comments, I'll try to answer :-)

Tags: haskell visual modeling emf diameta gmf openarchitectureware