Mittwoch, 20. Februar 2008

What Does it Need to Automatically Resolve Names in Programs

A big part of a programming language's (and thats true for all textual languages defined with on context-free grammar) static semantics deals with the resolution of names. Best example: you declare a variable, giving it a name; you later use that variable by referencing the declaration, using that name. How can one describe this part of a language's static semantics so that automatically generated editors/compilers can resolve names automatically?

The identity of an element is a value that uniquely identifies this element within a program. The language defines a function (1) that assigns each element of a language instance an identity. Example identities can be the element itself, the name of the element, or more complex constructs like full qualified names. An identifier is a value used to identify a model element based on the element's identity. In simple languages, identifier can often be used directly to identify elements: if an identifier and the identity of a element are the same, this identifier identifies this element. The many languages, however, require more complex identification, including name spaces, name hiding, imports, etc. In those cases, an identifier depends on the context it is used in. The language must define a function (2) that assigns a set of possible global identifiers to an identifier and its context. These global identifiers are then used to find a element with an identity that matches on of those global identifiers.

When we describe a language with meta-modeling, all model elements are objects of given meta-classes. Identification for a specific language can easily be programmed by implementing a simple interface (here based on EMF):
  1. public Object getIdentitiy(EObject object);
  2. public Object[] getGlobalIdentities(Object identifier, EObject context);
With this interface, and language engineers implementing it for their languages, our Textual Editing Framework TEF can simply customize name resolution and aspects of code-completion for languages with specific identification mechanisms.

We will try in the future to use this interface to implement an identification scheme for a language with a complex name-space based identification mechanism. See, if it really is enough to describe identification sufficiently.

Montag, 18. Februar 2008

Textual Modelling and More Than Text Editors

On the 20th March 2008, we will release the first major version of our Textual Editing Framework. We take this as an opportunity to talk about existing frameworks and new ways to facilitate text editors for the editing of models.

"Text" Editors for Domain Specific Languages

There are several projects that try to ease the pain of creating text editors for your textual (domain specific) (modeling) language. Based on the eclipse platform, these projects created frameworks that allow to describe a textual notation and generate a "text" from this description automatically. Some of these projects are:
What all of this frameworks have in common is that they create editors that allow users to edit text files. Consequently, these generated editors are text editors.

Beyond Text Editors

Text editors, nothing wrong with that. But, to use a file edited with such an editor, it has to be transformed into a model before. So why do we use text files with concrete syntax as artifacts to store models? The reasons are manifold, but reviewed carefully, most of them are doomed to become obsolete. Storing models, programs, whatever, in concrete syntax is still the favored way of persistence, because accepted storage and versioning systems are tailored for that. CVS, SVN and most of the commercial products, all rely on text-file comparison. Text files are also preferred, when it comes to migrating sources from one language version to another. Taking models from one meta-model version to the next, is still a risky task. And even it is not easier with concrete syntax, we are at least used to migrate concrete syntax files with aged but proven technology like regular expressions.

Anyway, all these problems that hold us back from persisting models as models rather than as text, are about to be solved. Projects like EMF's compare or teneo allow to compare and store models as models. And, there are similar projects behind closed doors at SAP or IKV (just the two I happen to know). Once this technology become more accepted, the need for "text" editors that edit models and not text increases.

TEF's Three Editor Kinds

To promote the idea of text editors that work on model (XMI) files, we integrated the support for different types of editors into our own framework for textual modeling. In TEF we distinct three different editor kinds, for three different purposes. Text editors are the usual editors that edit the textual model representation and not the model. Textual model editors are actual model editors. When loaded they create a textual representation for the edited model, the user can change it, and when stored, a new model is created from the user changed text representation. The third editor kind allows to edit a partial model. These editors can be embedded into already existing model editors (host editor), like graphical or tree-based editors. These editors show in a small overlay window and edit only a part of the host-editors model.

The last two editor kinds require to create an initial textual representation for a model. This means they have to pretty print the model. To do that, they have to chose the right representation, when multiple representations are possible for the same model constructs, and they have to generate white-spaces (layout information), which is not part of the model. TEF solves both problems by allowing language engineers to add according clues to the language notation. The language engineer can prioritize notation elements to favor one of multiple possible representations, and language engineers can add white-spaces roles to the notation that allow editors to intelligently create breaks, spaces and indentations.

to be continued ...

Upcoming posts will discuss pretty-printing and textual modeling embedded in graphical editing in more detail. We also want to talk about identifiers and references, which are still causing pain in all frameworks. We will keep you posted about TEF marching towards its first release.