How to Bootstrap a Language Workbench

Andreas Prinz

and Alexander Shatalin

University of Agder, Department of ICT, Agder, Norway

JetBrains, Prague, Czech Republic

Keywords:

Language Workbench, Bootstrapping, Metamodelling.

Abstract:

Language workbenches are designed to enable the deﬁnition of languages using appropriate meta-languages.

This makes it feasible to deﬁne the environments by themselves, as the meta-languages are also just languages.

This approach of deﬁning an environment using itself is called bootstrapping. Often, such bootstrapping is

difﬁcult to achieve and has to be built deeply into the environment.

The platform Meta-Programming System (MPS) has used bootstrapping for its own deﬁnition. In a similar

way, the environment LanguageLab is using bootstrapping for its deﬁnition. This paper reports the imple-

mentation of LanguageLab in MPS thereby also porting the bootstrapping. From the experiences general

requirements for bootstrapping language workbenches are derived.

1 INTRODUCTION

Meta-modelling (Gonzalez-Perez and Henderson-

Sellers, 2008) is an approach to deﬁne languages us-

ing meta-languages. In turn, these languages can

be used to deﬁne speciﬁcations (programs) of these

new languages. Typically, one would use a meta-

modelling environment, also called language work-

bench

(Fowler, 2005; Stoffel, 2010; Erdweg et al.,

2013; V

olter, 2014), to deﬁne languages and meta-

languages. The meta-languages are also languages

and can be deﬁned using the same meta-languages.

This process, called bootstrapping, is mainly an ad-

vantage for the workbench developers. It is typi-

cally not visible to the users. This paper will dis-

cuss two language workbenches, namely MPS (Cam-

pagne, 2014; Pech et al., 2013) and LanguageLab

(Gjøsæter and Prinz, 2013).

The open-source industrial-strength Meta-

Programming System (MPS) is provided by the

company Jetbrains. MPS has several meta-languages

covering a wide range of language-design elements

in order to support comprehensive language design.

All the meta-languages within MPS are deﬁned using

MPS itself making the platform bootstrapped. MPS

features a language called Base Language resembling

Java, which is then available for language extension

and development inside MPS. For example, it is

There are also grammar-based language workbenches

in addition to the meta-modelling environments.

possible to deﬁne new constructs for Java (Base

Language) within MPS. In the project mbeddr (Szab

et al., 2014), MPS provides an almost complete

deﬁnition of C++, allowing C++ to be used and

extended within MPS. This is exactly what mbeddr

does: extending C++ in MPS with state machines and

units for use in embedded device programming.

LanguageLab is an academic project at the univer-

sity of Agder, Norway. It is not concerned with an in-

dustrial strength environment, but rather with the con-

cepts that are needed to make meta-modelling user-

friendly and feasible. The main goal of LanguageLab

is to show the essential concepts of meta-modelling

in a clear and understandable tool, such that it can

be used in university teaching (Gjøsæter and Prinz,

2011). In the same way as MPS, also LanguageLab

is bootstrapped such that the few meta-languages of

LanguageLab are deﬁned within LanguageLab.

MPS and LanguageLab have different focus. The

general idea of MPS is to provide the user with as

much as possible help in deﬁning languages and us-

ing known notation when possible. This leads to the

fact that MPS is based heavily on Java-like languages

for the deﬁnition of most aspects in the platform. Lan-

guageLab is focused on a clean environment, and in

this context, it tries to avoid exposing the underlying

language of the platform to the user. Although both

platforms are implemented in Java, this is very visi-

ble in MPS, but not at all visible in LanguageLab.

Based on the strengths of MPS, a project was run

Prinz, A. and Shatalin, A.

How to Bootstrap a Language Workbench.

DOI: 10.5220/0007398203450352

In Proceedings of the 7th International Conference on Model-Driven Engineering and Software Development (MODELSWARD 2019), pages 345-352

ISBN: 978-989-758-358-2

345

to implement LanguageLab in MPS. This is of inter-

est for LanguageLab, because it puts LanguageLab

onto an industrial-strength platform, thereby improv-

ing the quality of LanguageLab. This is also of inter-

est for MPS, as it challenges MPS to handle a new set

of meta-languages.

In this paper, we describe this implementation, its

results and general conclusions from it. We start with

an introduction of essential terms and concepts of

meta-modelling in Section 2. In Section 3 we discuss

how LanguageLab can be described using MPS. Then

we describe the process how to bootstrap Language-

Lab in MPS in Section 4. In Section 5 we extract

the general requirements for successful bootstrap. We

discuss the project and possible alternatives in Section

6. Finally, we conclude in Section 7.

2 META-MODELLING IN MPS

AND LANGUAGELAB

This section introduces the concepts and terms used

in meta-modelling in general, and in LanguageLab

and MPS in particular. We normally use the terms

of MPS in this paper, and indicate the different terms

used in LanguageLab. We also indicate the terms used

in Xtext for convenience. Meta-modelling is an ap-

plication of model-driven development (Atkinson and

uhne, 2003) to language engineering and compiler

construction. Instead of implementing language han-

dling tools, e.g compilers, a model of the language

is created. From this model, tools are automatically

generated (Nytun et al., 2006). This way, languages

can be designed quickly for the programming tasks at

hand (Ward, 1994).

A language model has several different aspects,

which together give a complete description of all im-

portant properties of the language. There are the as-

pect groups of structure, syntax, and semantics, as

well as a group of tool-related aspects. In this section,

we only look into the aspects that have been used in

the project.

2.1 Structure (Abstract Syntax)

The structure (abstract syntax, meta-model) aspect

deﬁnes the concepts that are used in the language

and their relationships with each other. Language-

Lab uses the term ’type’ instead of ’concept’. Xtext

uses EMF for the deﬁnition of the meta-model

, and

a ’concept’ is represented by a ’class’. Concepts can

Please note that Xtext often auto-generates the meta-

model from the grammar.

own properties (of basic types) and children (enclosed

concepts). Moreover, concepts can have references

to other concepts. Properties are called ’attributes’

in LanguageLab and EMF, while children and refer-

ences are called ’aggregates’ and ’references’, respec-

tively, in LanguageLab. In EMF, references and chil-

dren are represented by associations, where children

are contained associations. A concept can have a par-

ent concept in terms of inheritance.

A language can be used by creating a speciﬁcation

(a program) in it. In this case, language concepts are

instantiated into a node structure, where each node

is an instance of a concept. Nodes have values (in-

stances of properties), sub-nodes (instances of chil-

dren), and links to other nodes (instances of refer-

ences).

2.2 (Concrete) Syntax

The concrete textual syntax, called editor in MPS, de-

ﬁnes how the speciﬁcations should look for the user.

In MPS and LanguageLab the syntax is deﬁned based

on the structure, while for Xtext the structure is de-

rived from the syntax (grammar)

. MPS uses a pro-

jectional editor (V

olter et al., 2014), which means

that the editor is presenting the internal node struc-

ture based on the syntax description. LanguageLab is

based on a grammar-approach with LR analysis. The

differences between the two approaches are quite se-

rious in terms of user experience and implementation.

However, for the sake of bootstrapping, the difference

is less important.

2.3 (Dynamic) Semantics

The meaning of the speciﬁcations of our new lan-

guage is deﬁned in the semantics. There are two main

ways to do this, namely transformations (compiler)

and executions (interpreter). For reasons of simplic-

ity, only generators are considered here, which are

called ’transformations’ in LanguageLab. Semantics

is out of scope of Xtext, which is mostly concerned

with the front-end, but can connect to semantics tools

within Eclipse. MPS features a template-based gener-

ation with very sophisticated expressions, while Lan-

guageLab has a very simplistic pattern-based trans-

formation language.

There is an option in MPS to derive the structure from

a grammar. Similarly, Xtext allows to base a grammar on

an existing meta-model (structure).

MODELSWARD 2019 - 7th International Conference on Model-Driven Engineering and Software Development

346

3 LANGUAGELAB IN MPS

The ﬁrst step for moving LanguageLab (LL) to MPS

is to deﬁne LanguageLab in MPS as shown in Fig-

ure 1. The LL generator, structure, and editor meta-

languages are deﬁned in MPS. Finally, an LL Petrinet

language is deﬁned as a sample test language on top

of those meta-languages.

Figure 1: Deﬁning Petrinet in LanguageLab, which is de-

ﬁned in MPS.

3.1 Structure Language

The initial LanguageLab structure language is deﬁned

using standard MPS. In the ﬁrst place, the language is

not yet a meta-language, but just a plain language pro-

viding the following concepts: Type, Property (with

specializations Attribute, Aggregate, and Reference),

AttributeType, Enumeration, and EnumElement.

When the types of the LanguageLab structure

language are used, they are translated into concept

declarations of the MPS structure meta-language.

This turns the LanguageLab structure language into

a meta-language.

3.2 Editor Language

Textual syntax in LanguageLab is based on a gram-

mar language that is ﬁnally translated into an LALR

parser. The editor is using the parser to read input and

a pretty printing tool to show the current text. MPS

works differently. Here, the editor is projectional, and

no parser is needed.

Fortunately, the descriptions of an MPS editor and

a grammar are similar enough to be able to translate

a LanguageLab description into an MPS description.

This is mostly due to both of them being quite declar-

ative. Again, the LanguageLab textual syntax lan-

guage is so far only a language. It becomes a meta-

language because the editor descriptions are trans-

lated into MPS editor language constructs.

3.3 Generator

The transformation language of LanguageLab is very

simplistic compared with the generator language used

by MPS to describe model-to-model transformations.

Therefore, the generator language for LanguageLab

in MPS is an adaptation of the MPS generator lan-

guage, adapted to the LanguageLab structure primi-

tives. It is simpliﬁed and only provides the genera-

tor primitives needed for the bootstrap, i.e. the Lan-

guageLab and Petrinet generators.

3.4 Testing with Petrinets

A simple Petrinet language was ﬁrst built within plain

MPS, and then again with the three LanguageLab lan-

guages explained in this section. With both versions it

was possible to write Petrinet speciﬁcations, generate

Java code from them and ﬁnally run them.

In the case of LanguageLab, the Petrinet lan-

guage description was ﬁrst generated into MPS meta-

languages, and from there into Java.

The user experience is almost the same for the

MPS version and the LanguageLab version, which in-

dicates that the two versions are very similar. In addi-

tion, the code generator from Petrinet to Java gener-

ates the same code in both cases.

4 BOOTSTRAPPING

The deﬁnition of LanguageLab in MPS allows other

languages to be deﬁned in LanguageLab, as shown

for the Petrinet language. But can we do the same

for the LanguageLab languages? The process would

be the same as for Petrinet: ﬁrst, the description in

LanguageLab is translated to MPS, and then down to

Java, which is ﬁnally executed (Figure 2). The ini-

Figure 2: Generation steps.

tial languages deﬁned in Section 3 relate to the last

step. Deﬁning LanguageLab in LanguageLab (the

ﬁrst step) introduces a deﬁnitional cycle which might

spoil the proper function of LanguageLab.

In describing the bootstrap, we distinguish be-

tween the bootstrap situation we want to achieve, and

the creation of this situation in the tool. We start

by discussing the bootstrap situation, before we jump

into the process to create this situation.

How to Bootstrap a Language Workbench

347

4.1 Bootstrap Situation

The ﬁnal state after bootstrapping is to have a com-

plete description of LanguageLab using Language-

Lab, as shown in Figure 3. This ﬁgure depicts the

Figure 3: Ideal bootstrap situation. All languages are de-

ﬁned using LanguageLab (LL).

three LanguageLab languages in their meta-language

role on the left, and in their language role on the right.

Still, the languages are the same as indicated by the

same name.

There are two kinds of dependencies in Figure 3:

use dependencies and references. A use dependency

is a connection between a meta-language and a lan-

guage, i.e. an arrow from the right to the left. Es-

sentially it means that a description is dependent on

the language it is written in. A reference is given be-

tween languages on the same meta-level. In our case,

both the editor language and the generator language

depend on the structure language, as the editor and

the generator descriptions always refer to their con-

cept description.

We see in Figure 3, that the structure language is

central to the bootstrap because of several reasons.

• It has ﬁve incoming dependencies.

• It is the only language with incoming references.

• It is needed already for the bootstrap situation.

• In addition, it is the only language with an internal

deﬁnition loop (Type being deﬁned by a Type).

Due to this central role of the structure language, we

focus on it now.

Based on the initial languages described in Sec-

tion 3, we can deﬁne the LanguageLab structure lan-

guage using the initial LanguageLab structure, editor,

and generator languages, see Figure 4.

The task for bootstrapping the structure aspect is

to replace the LLstructure:MPS language to the left in

Figure 4 with the LLstructure:LL language.

Figure 4: Preparing bootstrap: Deﬁning LanguageLab on

itself, but using MPS.

In order to make this new structure language us-

able, it has to be connected to adapted editor and gen-

erator languages, as shown in Figure 5. The adap-

tation is quite simple aligning the editor and genera-

tor languages with the references structure language,

which is structurally the same in all cases.

The original LanguageLab meta-languages to the

left in Figure 5 are deﬁned using MPS. Using these

languages, a bootstrapped version of the structure lan-

guage is deﬁned and connected to copies of the gen-

erator and editor languages with the change in their

reference dependencies. This step can be repeated as

shown in Figure 5. For the bootstrap process, we need

to replace the initial structure language with the boot-

strapped structure language in order to complete the

cycle. When this is done, the other meta-languages in

the middle column of Figure 5 need to be adapted by

way of their references.

4.2 Bootstrap Process

We could extend the process depicted in Figure 5 sev-

eral times, but it only creates a sequence of languages

and not a loop (a language deﬁning itself) as needed

for the bootstrap. For the creation of the bootstrap

situation, we ﬁrst look at how a bootstrap process is

done in LanguageLab and MPS individually in order

to construct a process for LanguageLab in MPS.

LanguageLab has two features to allow a boot-

strapping process. The ﬁrst feature is that Language-

Lab is interpreted, that is the language description

(ﬁle) is used as it is. This can be exploited by sim-

ply changing the dependency in the language descrip-

tion ﬁle (i.e. outside the LanguageLab platform) in or-

der to establish the bootstrapping situation. A second

helpful feature of LanguageLab is that each language

use is connected to its language deﬁnition via an in-

terface, where the actual language can be exchanged

when the instance is loaded. This means that there is

no direct connection between language use and lan-

guage deﬁnition. With these interfaces, bootstrapping

is even possible within the platform itself.

MODELSWARD 2019 - 7th International Conference on Model-Driven Engineering and Software Development

348

Figure 5: Situation before bootstrap.

MPS is a generated platform, where the language

description is translated into Java code, see also Fig-

ure 2. MPS features a very strong connection between

nodes and their concepts, such that it is essentially

impossible to change the concept of a node. This im-

plies that the bootstrap process can only happen by

inﬂuencing the generated code, which was done for

the MPS bootstrap.

For LanguageLab in MPS, we therefore have to

generate the same Java code for the concept declara-

tions of the bootstrapped LanguageLab structure lan-

guage as we have already generated for the initial

LanguageLab structure language. In MPS, two con-

cept declarations are generated to the same code when

they have the same name, the same concept ID and are

in the same language

. We achieve the last point by

collecting all the initial and bootstrapped concepts in

one language. In this combined LanguageLab struc-

ture language the two versions of the language have

different names to begin with.

For the generation of the concept IDs in MPS, the

node ID of the concept deﬁnition is used as default.

This can be changed to the node ID of the initial Lan-

guageLab deﬁnition.

Based on these general considerations, the boot-

strap process for the structure language has three

stages: prepare, bootstrap, and beautify.

4.2.1 Preparation

In the ﬁrst stage, the source is changed, but the gen-

erated code is left untouched. This allows running the

old code. There are three steps as follows.

Source Code Control. Put the generated code into

source code control (SCC). Normally, only the

language description is put into SCC. However,

for the bootstrap it is important to keep the gener-

ated code, as this is used to load the languages.

Without the generated code, it is impossible to

load the bootstrapped language, because the code

In MPS, languages are deﬁned in so-called modules.

is used in loading and it cannot be generated with-

out the code itself.

ID Handling. Insert the initial concept IDs for the

generation of the bootstrapped concepts includ-

ing IDs for the attributes, references and children.

This step relates to the identifying property for

concepts consisting of name, ID, and language.

Remove Initial. Change the names of the boot-

strapped concepts to be the same as the initial con-

cepts. Remove the initial concepts and related ed-

itor and generator. This is safe to do as the gener-

ated code and the loaded code are still available.

Both of them will be replaced by the newly gen-

erated code from the bootstrapped concepts in the

next step.

4.2.2 Bootstrapping

In the second stage, the generated code is changed.

This will invalidate some of the deﬁnitions, which

have to be ﬁxed. It involves the following four steps.

Regenerate. In this step, the old generated code is

removed and new code is generated. The newly

generated code for the bootstrapped concepts is

more or less a copy of the old generated code for

the initial concepts.

Fix Meta-language References. This step is related

to the type of the references between meta-

languages. The editor and the generator meta-

languages reference structure concepts that used

to be deﬁned by the initial concepts. After boot-

strap, they are deﬁned by the bootstrapped con-

cepts, and therefore the two languages have to be

adapted. Due to the structural equivalence of the

initial and the bootstrapped concepts, this is a sim-

ple mechanical replacement and also the gener-

ated code is almost the same as before.

Fix Language Descriptions. After we have changed

the editor and generator languages, we also need

to adapt the LanguageLab editor and generator

deﬁnitions, which is again a simple mechanical

replacement.

How to Bootstrap a Language Workbench

349

Regenerate Again. Finally, LanguageLab is gener-

ated by LanguageLab. This completes the boot-

strapping process and establishes the correct boot-

strap situation for the structure meta-language.

4.2.3 Beautifying

Although we have achieved the bootstrap situation,

we still have a special ID handling in place. This is

removed in the third stage as follows.

Nice IDs. Change the concept IDs of the boot-

strapped concepts to the IDs of the initial concepts

(that are now deleted).

Regenerate and Finish. Finally, the bootstrap pro-

cess is ﬁnished and we can rerun it as often as

needed, even with changes in the deﬁnitions. We

are back to the standard handling in MPS.

The process worked out exactly as planned. Af-

ter aligning the Petrinet language deﬁnitions to the

new LanguageLab, also the tests with the Petrinet lan-

guage still worked out. All the code can be found in

the LanguageLab git repository (LanguageLab, 2018)

and the project is built on the JetBrains build server

(JetBrains, 2018).

4.3 Bootstrapping the Editor

After the central part of bootstrapping the structure

language is done, the remaining languages are easy

to add. To test this, a bootstrapped editor language is

created using the following steps.

Deﬁning the Editor Structure. The LanguageLab

structure is used to deﬁne the structure of the

LanguageLab editor language.

Deﬁning the Editor Generator. The generator for

the editor language is deﬁned using the Language-

Lab generator language.

Generating. Code for the editor language is gener-

ated such that the language is usable.

Deﬁning New Editors for Structure and Editor.

New deﬁnitions of the editors for the structure

language and the editor language are deﬁned.

Regenerate. The bootstrap is more complete with

this regeneration as now we have a bootstrap of

both structure and editor.

A similar process works also for the generator lan-

guage, completing the bootstrap for all three Lan-

guageLab meta-languages. The success of the project

shows that MPS is able to facilitate bootstrapping of

another language workbench.

5 NEEDED TECHNOLOGY

Based on the project, we extract general conclusions

about bootstrapping for meta-model-based language

workbenches. In particular, we look into the elements

needed for a bootstrap to work in the two parts: boot-

strap situation and bootstrap process. Moreover, we

consider a general process of porting a bootstrap to

another workbench.

5.1 Bootstrap Situation

When we have created a bootstrap situation, we can

continue using it as is or change elements of the boot-

strapped language.

Keeping the Cycle. means that the language work-

bench is able to express the cyclic dependency of

the bootstrap situation.

Changes. A change in the bootstrap situation can be

a problem because the deﬁnition could be invali-

dated by the changes. This is about using the old

deﬁnition in order to create the new one having a

distinct point where the change is taken.

Keeping a bootstrap situation is easy for language

workbenches, as the connection between language

deﬁnition and language use is the core of a language

workbench. One way to make it work is to have two

different representations of the language: as a lan-

guage description for the deﬁnition role and as code

for the use role, as in MPS and EMF/Xtext. Alterna-

tively, the language can be loaded twice for these two

roles, as in LanguageLab.

For handling changes, in case of MPS and

EMF/Xtext, the point of change of the language is

when the new code is generated. In LanguageLab, the

point of change is when reloading the deﬁnition. In

both cases, the language deﬁnition is used in a read-

only mode thus allowing changes to the new deﬁni-

tion using the old deﬁnition.

5.2 Creating Bootstrap

Creating a bootstrap situation requires the ability to

construct a type-instance loop.

Circularity. There needs to be a way to change the

association between type and instance for the

bootstrapped languages.

In normal operation, it is impossible to create cir-

cular deﬁnitions, as a language workbench would re-

quire a concept to be existing in order to create an

instance of it. This way, ’concept’ cannot easily be

an instance of ’concept’. The creation of the circular

deﬁnitions is the core of the bootstrapping process.

MODELSWARD 2019 - 7th International Conference on Model-Driven Engineering and Software Development

350

In MPS (and EMF), there are three versions of any

language: ﬁrst, the language description as instances

of the meta-languages. Second, this description is

generated to Java. Third, the compiled Java code can

be loaded (and thereby activated) in MPS. The two

ﬁrst versions are available as ﬁles and can be stored

in a SCC, while the last one is transient. This means

in order to create the cycle it is most easy to work on

the generated code as we have done here.

The situation in LanguageLab is slightly different,

given by its interpretative nature. The language de-

scription is loaded directly, and without an interme-

diate compilation step. Still, the deﬁning language is

loaded read-only and before its instances. Changes to

this language are not done until the next load of the

language. This way, in order to create a cycle the def-

inition ﬁle can be changed.

In order to make a language workbench ready for

bootstrap, it is important to provide an operation to

build an ”empty” circular deﬁnition, which can then

be extended at will. Such a deﬁnition eases the boot-

strap process considerably.

5.3 Porting Bootstrap

Collecting the experiences from our project, we rec-

ommend the following steps for the porting.

1. Before jumping into the circularity, the ﬁrst

step of the porting is the creation of the meta-

languages without the circularity using the meta-

languages of the available language workbench.

2. Deﬁne a second set of meta-languages which are

similar, but now deﬁned on the ﬁrst set. Still, the

meta-languages are not circular.

3. As described before, the most critical part of the

bootstrap port is the handling of the deﬁne-use cir-

cularity. Sort out the circularity by either adapting

the code generation or by creating a loop in the

workbench if that is possible. This will solve the

internal circularity of the structure meta-language.

4. Circularities that involve deﬁne, use, and refer-

ence links can now be established stepwise. The

editor and the generator can ﬁrst be deﬁned non-

circular in order to get the structure loop working.

Then they can be re-deﬁned in a circular way and

replace their previous deﬁnitions.

6 DISCUSSION

In this chapter, we discuss two issues we encountered

during bootstrapping.

6.1 Complete Bootstrap

The bootstrap in LanguageLab is complete in the

sense that only the language descriptions are used,

and the rest is given in the MPS platform. The sit-

uation is different for the MPS platform itself, which

has all its meta-languages deﬁned in MPS and gen-

erated down to Java, but in addition some extensions

to the underlying IntelliJ IDEA platform (Fields and

Saunders, 2006).

In the earlier LanguageLab, the bootstrap was also

given by a set of languages together with a platform.

In general, any bootstrap situation has to rely on a

platform, and the question is merely how much of

the platform has to be adapted to make the bootstrap

work. Because of the power of the MPS platform,

the LanguageLab bootstrap on MPS did not need any

extra code.

6.2 Forward Loop

Currently, the bootstrap is created by wrapping the

loop backwards, i.e. the IDs of the bootstrapped con-

cepts are changed to ﬁt the IDs of the initial concepts.

Alternatively, we could work the other way around.

We could change the IDs of initial concepts such that

they ﬁt with the bootstrapped concepts.

In general, these two possibilities look very simi-

lar and they have the same effect. In practice, a for-

ward loop changes the initial concepts. This inval-

idates all their instances. This means all these in-

stances have to be recreated. In addition, there is a

risk that the changed initial concept IDs crash with

the existing bootstrapped IDs. In order to reduce the

risk and to keep some sort of stability, the decision

was taken to wrap the loop backwards.

7 CONCLUSION

In this paper, we have shown how LanguageLab can

be bootstrapped in MPS. The experiences have been

generalized to requirements that have to be in place

for a bootstrap to work.

We have bootstrapped the LanguageLab structure

language including its internal deﬁnition-use cycle.

On the base of the structure language, also the Lan-

guageLab editor language was bootstrapped. The

languageLab transformation language has not been

bootstrapped, but is still partly based on MPS meta-

languages. As it does not introduce new references to

the bootstrap, we expect that it can be added with the

same ease as the editor language.

How to Bootstrap a Language Workbench

351

Apart form the general possibility of porting the

LanguageLab bootstrap to MPS, several technical

tricks had to be used to make LanguageLab ﬁt into

MPS. This is mostly due to the different philosophy

behind the two language workbenches, in particular

their differing views on language aspects.

For making a bootstrap work in general, a lan-

guage workbench needs to be able to use the same

language as deﬁning and deﬁned speciﬁcation, which

is a special case of the standard language workbench

functionality. Moreover, it has to keep the used lan-

guage stable and to allow changing the type of an in-

stance for introducing a loop. MPS, Xtext and Lan-

guageLab fulﬁll all these requirements.

ACKNOWLEDGEMENTS

We thank the reviewers for their helpful comments.

REFERENCES

Atkinson, C. and K

uhne, T. (2003). Model-driven devel-

opment: a metamodeling foundation. IEEE Software,

20(5):36–41.

Campagne, F. (2014). The MPS Language Workbench: Vol-

ume I. Fabien Campagne.

Erdweg, S., Storm, T. v. d., V

olter, M., Boersma, M.,

Bosman, R., Cook, W. R., Gerritsen, A., Hulshout,

A., Kelly, S., Loh, A., Konat, G. D. P., Molina, P. J.,

Palatnik, M., Pohjonen, R., Schindler, E., Schindler,

K., Solmi, R., Vergu, V. A., Visser, E., Vlist, K.

v. d., Wachsmuth, G. H., and Woning, J. v. d. (2013).

The state of the art in language workbenches. In Er-

wig, M., Paige, R. F., and Wyk, E. V., editors, Soft-

ware Language Engineering, number 8225 in Lecture

Notes in Computer Science, pages 197–217. Springer

International Publishing.

Fields, D. and Saunders, S. (2006). IntelliJ Idea In Action.

Dreamtech Press.

Fowler, M. (2005). Language workbenches: The killer-app

for domain speciﬁc languages? http://www. martin-

fowler.com/articles/languageWorkbench.html.

Gjøsæter, T. and Prinz, A. (2011). Teaching Computer Lan-

guage Handling - From Compiler Theory to Meta-

modelling, pages 446–460. Springer Berlin Heidel-

berg, Berlin, Heidelberg.

Gjøsæter, T. and Prinz, A. (2013). Languagelab 1.1 user

manual. Technical report, University of Agder.

Gonzalez-Perez, C. and Henderson-Sellers, B. (2008).

Metamodelling for Software Engineering. Wiley Pub-

lishing.

JetBrains (2018). Languagelab build server. https://team

city.jetbrains.com/viewType.html?buildTypeId=MPS

LanguageLab LlAll.

LanguageLab (2018). Languagelab git repository. https://

tools.uia.no/stash/scm/projects 2015/mps-language

lab.git.

Nytun, J. P., Prinz, A., and Tveit, M. S. (2006). Au-

tomatic generation of modelling tools. In Rensink,

A. and Warmer, J., editors, Model Driven Architec-

ture – Foundations and Applications, number 4066 in

Lecture Notes in Computer Science, pages 268–283.

Springer Berlin Heidelberg.

Pech, V., Shatalin, A., and V

olter, M. (2013). JetBrains

MPS as a tool for extending java. In Proceedings of

the 2013 International Conference on Principles and

Practices of Programming on the Java Platform: Vir-

tual Machines, Languages, and Tools, PPPJ ’13, pages

165–168. ACM.

Stoffel, R. (2010). Comparing language workbenches. In

MSE-seminar: Program Analysis and Transforma-

tion, pages 18–24.

Szab

o, T., Voelter, M., Kolb, B., Ratiu, D., and Schaetz,

B. (2014). Mbeddr: Extensible languages for embed-

ded software development. In Proceedings of the 2014

ACM SIGAda Annual Conference on High Integrity

Language Technology, HILT ’14, pages 13–16, New

York, NY, USA. ACM.

olter, M. (2014). Generic tools, speciﬁc languages. PhD

thesis, TU Delft, Delft University of Technology.

olter, M., Siegmund, J., Berger, T., and Kolb, B. (2014).

Towards user-friendly projectional editors. In Combe-

male, B., Pearce, D. J., Barais, O., and Vinju, J. J., ed-

itors, Software Language Engineering, volume 8706

of Lecture Notes in Computer Science, pages 41–61.

Springer International Publishing.

Ward, M. P. (1994). Language oriented programming.

Software-Concepts and Tools, 15(4):147–161.

MODELSWARD 2019 - 7th International Conference on Model-Driven Engineering and Software Development

352