Creating Python-Style Domain Speciﬁc Languages: A Semi-Automated

Approach and Intermediate Results

Weixing Zhang

1 a

, Regina Hebig

1 b

, Jan-Philipp Stegh

ofer

2 c

and J

org Holtmann

1 d

Department of Computer Engineering, Chalmers University of Technology, University of Gothenburg, Sweden

Xitaso IT & Software Solutions GmbH, Augsburg, Germany

Keywords:

DSL, Xtext, Textual Modeling, Grammar, Language Engineering.

Abstract:

Xtext is a well-known domain-speciﬁc language design framework and technology. It automatically generates

a textual grammar for a language, given a meta-model speciﬁed in Ecore. These generated textual grammars

are typically not user-friendly. Python-style languages are popular among developers for their usability and

conciseness. We aim to propose a systematic approach to transform a DSL with a generated grammar into

a Python-style DSL. To achieve this, we analyze the problems of grammars generated with Xtext, based

on a lightweight architecture description language. In response to these problems, we propose a general

semi-automated grammar adaptation approach. We apply the approach to two other DSLs to validate the

generalization of the approach. We also discuss the limitations of this approach and prospects for the future.

1 INTRODUCTION

In contrast to general-purpose programming lan-

guages (GPLs) like Java, domain-speciﬁc languages

(DSLs) are computer languages tailored for a partic-

ular application domain (Kosar et al., 2016). DSLs

come in a variety of forms and are employed in a wide

range of domains(do Nascimento et al., 2012). For

example, DSLs are used to improve the level of ab-

straction and automation in the application develop-

ment in the robotic domain (Nordmann et al., 2014).

But it is important to take into account the workload

that goes into creating the DSL (Mernik et al., 2005).

The good news is that there are many tools available

for designing and developing DSLs, like JetBrains

MPS, MontiCore, Xtext, Racket, etc. (Iung et al.,

2020). One of them is Xtext (Eclipse Foundation,

2022c), an open-source software framework that sim-

pliﬁes the development of DSLs. Xtext can generate a

complete DSL infrastructure, including parsers, link-

ers, compilers, etc. Developers utilize Ecore meta-

models to represent domain ideas and their relation-

ships when creating DSLs based on Xtext. From such

a meta-model, Xtext generates grammar that speciﬁes

https://orcid.org/0000-0003-2890-6034

https://orcid.org/0000-0002-1459-2081

https://orcid.org/0000-0003-1694-0972

https://orcid.org/0000-0001-6141-4571

the concrete syntax. The editor and its different com-

ponents are automatically generated from the meta-

model of this language as Xtext artifacts.

The grammar generated by Xtext tends to specify

languages that are not user-friendly to use. For exam-

ple, the generated DSLs include default requirements

that developers type in all keywords, use braces to an

extensive amount, etc. This leads to a high effort in

writing when programming in these DSLs. In con-

trast, the Python (Python Community, 2022) language

provides a very clean coding style, is renowned for in-

creasing programmer productivity, and is considered

easy to learn (Gmys et al., 2020). Both are properties

are also relevant and desirable for DSLs. However,

there is currently no systematic approach for convert-

ing DSLs to Python-like languages.

In this paper, we introduce an approach to semi-

automatically convert textual DSL grammars gener-

ated by Xtext to a Python-like DSL. This means that

the resulting languages will be easy to code, easy to

read, user-friendly, concise, and use whitespace and

indents instead of braces (Gmys et al., 2020). We de-

veloped the approach by developing an architectural

description language (DemoAdl) as an exemplar for

automatically transforming a DSL to a Python-like

language. Once our transformation worked for De-

moAdl, we evaluated the approach with additional

DSLs, Xenia and ACME. This way we validate the

210

Zhang, W., Hebig, R., Steghöfer, J. and Holtmann, J.

Creating Python-Style Domain Speciﬁc Languages: A Semi-Automated Approach and Intermediate Results.

DOI: 10.5220/0011744900003402

In Proceedings of the 11th International Conference on Model-Based Software and Systems Engineering (MODELSWARD 2023), pages 210-217

ISBN: 978-989-758-633-0; ISSN: 2184-4348

 2023 by SCITEPRESS – Science and Technology Publications, Lda. Under CC license (CC BY-NC-ND 4.0)

Metamodel

(Ecore file)

Concrete Syntax

(Xtext file)

Domain Program

(User code)

Generate

Grammar

Run MWE2

Run Runtime

and Program

conforms to conforms to

Figure 1: The relationship between different artifacts in the

Xtext-based MDSE solution.

generalizability of our approach and explore its limi-

tations.

2 BACKGROUND

As outlined in the introduction, Xtext is a frame-

work for developing DSLs, and Xtext-based Model-

Driven Software Engineering (MDSE) is a common

solution for developing DSLs (Behrens et al., 2008).

In this solution, the DSL developer uses an Ecore

meta-model to describe the concepts of the domain

and the relationships between the concepts (Stein-

berg et al., 2008). For example, “port” becomes a

class in the meta-model when using a meta-model

to describe concepts in the ﬁeld of system architec-

ture. Next, the concrete syntax is generated from the

meta-model by using the Xtext framework. Xtext pro-

vides Modeling Workﬂow Engine 2 (MWE2) (Eclipse

Foundation, 2022a), a declarative, externally conﬁg-

urable generator engine. After having a concrete syn-

tax, all Xtext artifacts can be generated by running the

MWE2 ﬁle. These artifacts actually make up the edi-

tor for the DSL, including linker, parser, type-checker,

etc., common components of editors, and editing sup-

port for Eclipse. After the editor is generated, code

written in the DSL could be resolved and supported

at runtime. Figure 1 shows the relationship between

the above concepts. When Xtext generates a tex-

tual grammar, it will generate a corresponding gram-

mar rule for each class or enumeration in the meta-

model and create an attribute in the textual grammar

for each attribute or association (i.e., reference or con-

tainment) in the meta-model. A grammar rule corre-

sponding to a class may contain multiple attributes,

and each attribute occupies a line of text. A grammar

rule corresponding to an enumeration contains multi-

ple alternative values, usually on the same line of text.

3 METHODOLOGY

As mentioned above, we developed the approach by

developing an architectural description language (i.e.,

DemoADL) for an example embedded system. The

DSL can be used to describe simple embedded sys-

Figure 2: A screenshot of part of the domain program with

a default Xtext style.

tem structures, which include hardware components

and software components. There are different types of

hardware components, and each software component

contains a number of sub-components. There are di-

rect links between hardware components and software

components, which together make up the system.

We created an Ecore meta-model that describes

the domain concepts from this system and generated

textual grammar from the meta-model by using Xtext.

This constitutes the default grammar for the concrete

syntax for DemoAdl. We used this DSL to code an

example program with a default style (we called this

program a “Default-style program”). We analyzed the

shortcomings of the grammar and the program con-

forms to it. We also created a draft of the program

to illustrate what it might look like in a Python-style

grammar. We call this program a “Python-like draft”.

Based on that analysis, we developed a systematic

approach to adapt grammars that were generated with

Xtext. The approach is based on grammar adaptation

rules in response to the problems analyzed from the

default-style DSL. We applied these rules to the gram-

mar Xtext generated for DemoAdl. To semi-automate

the grammar adaptations, we developed a script in the

form of an eclipse Java plug-in. After the adaptation

of the grammar, we generated an editor and wrote the

same program according to the newly adapted gram-

mar (we called this code a “Python-like program”).

This was to test whether we could successfully parse

Creating Python-Style Domain Speciﬁc Languages: A Semi-Automated Approach and Intermediate Results

211

such a program in the new editor.

To evaluate the generalizability of our approach,

we chose two other DSLs. Our selection criteria are

that the language 1) has an accessible homepage and

2) with examples on the homepage, and 3) has a

downloadable Ecore meta-model. We apply the pro-

posed approach to these two languages to determine

whether the script and approach can be applied to cre-

ate Python-style languages.

4 RESULTS

We present our analysis, our semi-automated ap-

proach, and an evaluation of our approach.

4.1 Analysis

As mentioned in the methodology section, we ﬁrst an-

alyzed the shortcomings of the sample DSL (i.e., De-

moADL). We illustrate our ﬁndings with the help of

a snippet of the default style program in Figure 2. We

made the following observations about the grammar

generated by Xtext:

1. Inappropriate Position of Identiﬁer. In Xtext,

‘name’ is the default name for an element’s iden-

tiﬁer. However, when we use an attribute named

identiﬁer to identify an element (e.g., a software

component in our case language DemoAdl), then

it will default to a normal attribute and be placed

within braces. This means that, for example,

when we type in keyword SoftwareComponent,

we have to type in the left brace ﬁrst and then the

attribute identiﬁer. For example, in Figure 2 (line

22), attribute identiﬁer with value ‘swcomp1’ is

used to identify an element SoftwareComponent,

however, the attribute identiﬁer is existing inside

of braces in the second line which reduces the

brevity of the code. If the same content is ex-

pressed in Python, e.g., in Figure 3, the identiﬁer

value ‘swcomp1’ (line 1) will follow the keyword

SoftwareComponent to identify the element.

2. Heavy Separation of Code Blocks. The default-

style program uses both braces and commas to

separate and distinguish code blocks. For exam-

ple, PortGroup ‘portgroup1’ and ‘portgroup2’ are

on the same level while they are separated by a

comma symbol. Obviously, these commas are re-

dundant, because braces have already been able to

separate and distinguish them. In Python, for ex-

ample in Figure 3, ‘portgourp1’ and ‘portgroup2’

are separated by being on different lines though

there is no brace or comma for them. This is be-

cause there are indents to express hierarchy, and

Figure 3: Snippet of SoftwareComponent in the system

architecture description example, in Python style.

‘portgourp1’ and ‘portgroup2’ are on the same hi-

erarchy level.

3. Repetitive Keyword. There are different key-

words with the same functional implication. For

example, there are two keywords softwarecompo-

nent and SoftwareComponent, which are highly

redundant in function. This also reduced the us-

ability of the language.

4. Nested Braces. There are many nested braces, for

example in Figure 2, after typing in a keyword,

it’s necessary to open a brace. Next, we should

type in the keyword PortGroup and go into a brace

again. These nesting braces are unnecessary and

redundant, which increases the complexity of the

code. In Python, braces are avoided by having a

whitespace-sensitive syntax.

The draft shown in Figure 3 shows how the pro-

gram from Figure 2 could appear in a Python-style

language. The envisioned code in Figure 3 uses

whitespace and indentations to deﬁne and separate

code blocks, which greatly improves the conciseness

of the code. Identiﬁer of e.g. SoftwareComponent

directly follows after the keyword ‘SoftwareCompo-

nent’ (cf. line 1 in Figure 3), which makes the code

more readable. There are no more braces and the

number of keywords and symbols is greatly reduced.

4.2 The Semi-Automated Approach

As mentioned earlier, we developed a semi-automated

approach to adapt a generated grammar to become

more like Python. On the one hand, we develop a

script that applies some changes automatically. On

the other hand, we require the language engineer to

take some speciﬁc decisions that must be done by

hand. The adaptations that are automatically com-

pleted by the script are removing braces, reposition-

ing attributes, and removing commas. Hand-crafted

adaptations address which keywords need to be re-

ﬁned. In the following we describe these adaptations

in more detail:

MODELSWARD 2023 - 11th International Conference on Model-Based Software and Systems Engineering

212

Remove Braces and Introduce White-Space

Awareness. Removing all braces directly from the

grammar deﬁnition may cause errors, such as left

recursion errors(Bettini, 2019), which will prevent

the creation of a textual editor.

Therefore, the functionality of the braces needs to

be substituted with the use of whitespace and indents

to deﬁne code blocks. Thus, we need the language to

be whitespace-aware (Eclipse Foundation, 2022b). To

this end, the script introduces the following changes:

Import Required Features. Change the

reference in the grammar deﬁnition ﬁle

from org.eclipse.xtext.common.Terminals to

org.eclipse.xtext.xbase.Xbase. In addition, im-

port Xbase to refer to EClassiﬁers from that

model. This gives access to features that allow

white-space-aware grammars in Xtext.

Create BEGIN/END Terminals. Include

whitespace-aware blocks in your language

by using synthetic tokens in the grammar of

the form ‘synthetic:<terminal name>’. An

example using BEGIN/END is shown in Figure 4.

Redeﬁne Expression. Inherits expressions

from Xbase and redeﬁnes the syntax of block

expressions by overriding the deﬁnition of

xbase::XExpression.

Reposition Attribute Identiﬁer. With the help of

the script, we moved the attribute identiﬁer from its

original position to after the keyword with the same

name as the grammar rule. For example, Software-

Component would be exactly followed by the attribute

identiﬁer. Here, the script uses regular expressions to

ﬁnd the attribute identiﬁer and move it. If the iden-

tiﬁer is called name, we do not need to do anything

with it.

Remove Commas. In this step, we removed com-

mas that separate code blocks. For example, if there

are multiple ports under the same PortGroup (cf. line

11 & 12 in Figure 5), we do not need to separate these

ports with commas because whitespace and indenta-

tions are used instead.

Reﬁne Keywords. In this step, functionally redun-

dant keywords are manually removed. The aforemen-

tioned keywords SoftwareComponent and software-

component, e.g., were functionally redundant and we

removed one of them (in our case, we kept the up-

per case one). We did not implement this removal in

the script, because the keywords are language-speciﬁc

and people make different decisions about what to

keep. At the same time, we also did not implement

the removal of the BEGIN/END related to them in the

script. We will address these two automated opera-

tions in our future work by conﬁgurable rules with

a ﬁnite set of options. For manually removing func-

tionally redundant keywords, we recommend deﬁning

a rule, e.g., to remove the keyword which is written

entirely in lowercase. However, our script automat-

ically removes the keyword ‘identiﬁer’, because, in

our envisioned draft, the value of the identiﬁer should

directly follow the keyword (e.g., SoftwareCompo-

nent) without the existence of the keyword ‘identi-

ﬁer’, which would make the code more concise.

When the script adapts the grammar, it uses reg-

ular expressions to search for the target texts in the

entire grammar text, and then performs operations on

it, including deletion, modiﬁcation, etc.

4.3 Evaluation

With the above modiﬁcations, the grammar of De-

moADL was changed. We generated the Xtext arti-

facts for the language by running the MWE2 work-

ﬂow ﬁle. We wrote a program (cf. Figure 5) that con-

forms to the newly adapted textual grammar, which

was parsed successfully by the generated editor.

To evaluate the usability and generalizability of

the proposed approach, we applied it to two additional

DSLs, Xenia and ACME, which we selected based on

the criteria described above. The basic information of

the two DSLs is shown in Table 1.

Grammar Generation with Xtext. The Ecore

meta-model of ACME is from the Atlantic Zoo (At-

lanMod, 2019). To fulﬁll all technical constraints nec-

essary for the generation of model code and grammar

with Xtext, some small adaptations were necessary:

1. We ﬁlled in the namespace values (i.e., ‘Ns Preﬁx’

and ’Ns URI’) for all packages in the meta-model.

2. We ﬁlled in the value (i.e., ‘Instance Type Name’

for all the types under the package primitivetypes.

3. We changed the lower-bound value of two at-

tributes under the type Link from 1 to 0.

We then generated a textual grammar from both

DSLs’ meta-models using the Xtext framework.

Applying the Approach. With the proposed ap-

proach, we adapted both DSLs to a Python-like DSL

with the help of our script. All manual steps were

performed by the ﬁrst author of this paper. For both

ACME and Xenia, executing these manual steps took

less than 30 minutes each.

Creating Python-Style Domain Speciﬁc Languages: A Semi-Automated Approach and Intermediate Results

213

(a) Grammar rule SoftwareComponent before adaptation. (b) Grammar rule SoftwareComponent after adaptation.

Figure 4: Comparison of grammar rules SoftwareComponent before and after adaptation.

Table 1: The two languages chosen for the evaluation.

Language Domain Language meta-model Homepage

elements Source

Xenia Generate web pages 14 (Rodchenkov, 2019) (Rodchenkov, 2020)

ACME SW Architecture description 16 (AtlanMod, 2019) (ABLE Group, 2011)

Figure 5: Screenshot of part of the example program for the

DemoADL language with a Python-like style in eclipse.

Outcome. An example program for the grammar

that Xtext generated for Xenia is shown in Figure 6-

(b) while the program for the resulting Python-like

grammar of Xenia is shown in Figure 6-(c). For com-

parison, two programs correspond to the “app Main”

example from the Xenia home page (Rodchenkov,

2020) (shown in Figure 6-(a)).

The comparison shows that the program in (c) is

much more concise than the one in (b) because there

are fewer keywords and nesting. Like Python, the pro-

gram in (c) uses whitespace and indents to express

hierarchy. The comparison to the original program

(Figure 6-(a)) also shows that the resulting Python-

like grammar is much closer in terms of compactness

to the actual, intended grammar of Xenia.

An example program for the grammar that Xtext

generated for ACME is shown in Figure 8 while the

program for the resulting Python-like grammar of

ACME is shown in Figure 9. Similarly, the two

programs conform to the example “simple cs” from

the subpage “An Overview Of Acme” of the ACME

homepage (ABLE Group, 2011) (shown in Figure 7).

Again we can see that the Python-like program in

(c))contains much fewer lines of code, and there is

no need to input braces in the program. Every identi-

ﬁer (here e.g., the name) follows the main keyword to

identify a certain structure. Also, the comparison to

the original grammar shows that the Python-like style

is much closer to the original and intended grammar

of ACME (Figure 7) in terms of compactness.

Note that the original syntaxes of both Xenia and

ACME are quite different in style and neither is orig-

inally white-space sensitive. This shows that our ap-

proach and the script are applicable to diverse DSLs

and can be used by DSL developers to quickly reach

a Python-like grammar, which could then be used as

a basis for further reﬁnements of the grammar.

5 DISCUSSION

5.1 Threats to Validity and Limitations

Threats to Validity. As discussed in the evaluation

part, we applied the proposed approach to the two

DSLs Xenia and ACME. The results show that the

approach could be successfully used for these two

DSLs. However, to ensure generalizability, we plan to

apply the approach to additional languages. Although

we could show that our method provides a quick way

to adapt diverse Xtext-generated grammars to Python-

style languages, there are still some limitations.

Expressiveness of Language. Even after adapting

a grammar with our approach, there is often room for

further modiﬁcations to the grammar to improve the

expressiveness of the language itself. In the Xenia

MODELSWARD 2023 - 11th International Conference on Model-Based Software and Systems Engineering

214

(a) The example from Xenia official website.

(b) The same Xenia example according to grammar generated by Xtext. (c) The same Xenia example according to Python-like grammar.

Figure 6: Comparison of Xenia programs in different styles (The original example is from https://github.com/rodchenk/xenia).

Figure 7: ACME original syntax from https://www.cs.cmu.

edu/

∼

acme/docs/language overview.html.

example, we can change the keyword page to the ar-

row -¿, indicating a “progressive” or “link” relation-

ship as it was done in the original grammar. Such

special keywords are typical for DSLs. Our proposed

approach does not include such operations, since they

are highly language-speciﬁc. We focus currently only

on adapting a DSL with a default Xtext-generated

grammar to Python style. However, in future work, it

might be interesting to support such operations with

automation tools.

Automation of Grammar Modiﬁcation. We im-

plemented a small script in the form of an Eclipse

plugin to simplify grammar modiﬁcation. However,

the functionality of the script is limited. For example,

adding a colon : after a certain type of keyword is not

Figure 8: The example from Figure 7 in the syntax automat-

ically generated by Xtext.

supported by the script at present. A feasible solution

will be to extend the functionality to support various

Creating Python-Style Domain Speciﬁc Languages: A Semi-Automated Approach and Intermediate Results

215

Figure 9: The example from Figure 7 in the Python-like

syntax after our tool modiﬁed the generated grammar.

modiﬁcations of keywords.

Also, while adapting the grammar, one may en-

counter problems such as left-recursion errors. Other

than the focused change to white-space awareness, we

currently provide no additional support to help devel-

opers avoid changes that lead to these errors.

5.2 Future Work

As we mentioned above, in the future we will apply

our approach to more languages to evaluate general-

izability. In addition, we plan to apply the approach

to larger DSLs, for example, EAST-ADL. We hope

that this will also help us reﬁne our approach and ex-

tend the capabilities of the script. Namely, we hope

that we can address the previously mentioned limited

functionality of our script and the semi-automated na-

ture of our approach.

Converting a DSL generated from a meta-model

into a Python-like language can improve the lan-

guage’s simplicity, friendliness, and usability. How-

ever, these are all issues on the language appearance

level. In the future, we will discuss and explore how

to design a good DSL, including deﬁning the stan-

dards of what a good DSL is.

Another interesting and related topic is blended

modeling (Addazi and Ciccozzi, 2021), which refers

to modeling in different notations (such as textual,

graphical, etc.) at the same time. When creating a tex-

tual language for a DSL that already has a non-textual

notation, the approach in this paper can help create

a concise, user-friendly textual language in the ﬁrst

stage, thereby improving the user experience of mod-

eling activities (David et al., 2022). In future work,

we plan to evaluate our approach in this context.

6 RELATED WORK

Since the ﬁrst version of Xtext was released in 2006

(Efftinge and V

olter, 2006), the German company

itemis released several versions of Xtext. Eysholdt

and Behrens from the company brieﬂy introduced the

motivation and capabilities of Xtext in (Eysholdt and

Behrens, 2010). In addition, itemis also ofﬁcially re-

leased the Xtext User Guide, which introduces in de-

tail what Xtext is, how to use it and some of its in-

ternal principles (Behrens et al., 2008). This is the

technical manual that is the main reference for this

paper. Bettini’s book (Bettini, 2016) goes further and

shows how to develop DSLs using Xtext and Xtend.

Moreover, the book has a dedicated and independent

chapter to introduce Xbase, which is not included in

(Behrens et al., 2008) and it supplements the knowl-

edge about Xbase for us.

Mernik et al. in (Mernik et al., 2005) provide em-

pirical data and valuable experience on when and how

to develop DSLs, this study refers to these experi-

ences when designing the DSL. Neubauer et al. cus-

tomized the grammar generated from the Ecore meta-

model (Neubauer et al., 2015). However, their pur-

pose was to solve the problem that the Xtext gram-

mar generator did not create rules for meta-model

data types. In contrast, the modiﬁcation in this paper

aims to bring the grammar closer to Python. Manual

changes were made by Sredojevi to the DSL’s gram-

mar deﬁnition ﬁle in (Sredojevi

c et al., 2015). By

including keywords and identiﬁers, this change pri-

marily addresses the issue that the graphical repre-

sentation of the meta-model does not fully deﬁne the

grammar structure. In contrast, our approach replaces

the language’s overall style by modifying the entire

grammar deﬁnition ﬁle.

7 CONCLUSION

Xtext is one of the most commonly used methods for

developing DSL. It can be used to generate a textual

grammar from an Ecore meta-model. However, this

auto-generated grammar has a format that is often

considered cumbersome and difﬁcult to work with.

Python is a language known for its simplicity, which

helps programmers become more productive. We aim

to make it easy for DSL developers to create their

languages with a Python-style syntax, in the hope

that these DSLs would beneﬁt from the advantages of

Python’s syntax. In this paper, we analyze the primary

inadequacies of an auto-generated DSL (i.e., DSL

generated by Xtext) which is to describe the architec-

ture of an embedded system. Based on this analysis,

this paper presents an approach to semi-automatically

change a grammar that was generated with Xtext, so

that the DSL becomes a Python-like language. We

applied this approach to the design of the aforemen-

tioned lightweight example language and obtained an

intermediate result, a Python-like structure descrip-

tion language. We applied the approach to two ad-

MODELSWARD 2023 - 11th International Conference on Model-Based Software and Systems Engineering

216

ditional DSLs, Xenia and ACME, to validate the gen-

eralizability of our approach. The contribution of this

paper is a generalized approach for transforming gen-

erated DSLs into Python-like DSLs.

We intend to investigate the practical applications

of this approach in the future, e.g., the adaptation of

highly sophisticated and large DSLs in industrial set-

tings. In our future efforts, we intend to develop a

more complete system for the adaptation of automat-

ically generated grammar. We envision a rule-based

system that allows an engineer to conﬁgure a num-

ber of modiﬁcations of the grammar that, together,

change the concrete syntax signiﬁcantly. We believe

such a system will contribute to making Xtext more

attractive to language engineers who want to combine

work on an evolving and rapidly changing language

with a user-friendly and compact concrete syntax, a

combination that Xtext currently does not support.

REFERENCES

ABLE Group (2011). Acme homepage. At Carnegie Mel-

lon University, https://acme.able.cs.cmu.edu/docs/

language overview.html, Last accessed Nov 2022.

Addazi, L. and Ciccozzi, F. (2021). Blended graphical and

textual modelling for uml proﬁles: A proof-of-concept

implementation and experiment. JSS, 175:110912.

AtlanMod (2019). Atlantic zoo. https://github.com/

atlanmod/atlantic-zoo, Last accessed Nov 2022.

Behrens, H., Clay, M., Efftinge, S., Eysholdt, M., Friese,

P., K

ohnlein, J., Wannheden, K., and Zarnekow, S.

(2008). Xtext user guide. http://www.eclipse.org/

Xtext/documentation/, Last accessed Nov 2022.

Bettini, L. (2016). Implementing domain-speciﬁc languages

with Xtext and Xtend. Packt Publishing Ltd.

Bettini, L. (2019). Type errors for the ide with xtext and

xsemantics. Open Computer Science, 9(1):52–79.

David, I., Latifaj, M., Pietron, J., Zhang, W., Ciccozzi,

F., Malavolta, I., Raschke, A., Stegh

ofer, J.-P., and

Hebig, R. (2022). Blended modeling in commercial

and open-source model-driven software engineering

tools: A systematic study. Software & Systems Mod-

eling To appear.

do Nascimento, L. M., Viana, D. L., Neto, P., Martins, D.,

Garcia, V. C., and Meira, S. (2012). A systematic

mapping study on domain-speciﬁc languages. In IC-

SEA, pages 179–187.

Eclipse Foundation (2022a). Mwe2. https://www.eclipse.

org/Xtext/documentation/306 mwe2.html. Last ac-

cessed Nov 2022.

Eclipse Foundation (2022b). Whitespace-awareness.

https://www.eclipse.org/Xtext/documentation/

307 special languages.html. Last accessed Nov

2022.

Eclipse Foundation (2022c). Xtext homepage. https://www.

eclipse.org/Xtext/. Last accessed Nov 2022.

Efftinge, S. and V

olter, M. (2006). oaw xtext: A framework

for textual dsls. In Workshop on Modeling Symposium

at Eclipse Summit, volume 32.

Eysholdt, M. and Behrens, H. (2010). Xtext: implement

your language faster than the quick and dirty way. In

OOPSLA Companion, pages 307–309.

Gmys, J., Carneiro, T., Melab, N., Talbi, E.-G.,

and Tuyttens, D. (2020). A comparative study

of high-productivity high-performance programming

languages for parallel metaheuristics. Swarm and

Evolutionary Computation, 57:100720.

Iung, A., Carbonell, J., Marchezan, L., Rodrigues, E.,

Bernardino, M., Basso, F. P., and Medeiros, B. (2020).

Systematic mapping study on domain-speciﬁc lan-

guage development tools. ESEM, 25(5):4205–4249.

Kosar, T., Bohra, S., and Mernik, M. (2016). Domain-

speciﬁc languages: A systematic mapping study. IST,

71:77–91.

Mernik, M., Heering, J., and Sloane, A. M. (2005). When

and how to develop domain-speciﬁc languages. ACM

Computing Surveys (CSUR), 37(4):316–344.

Neubauer, P., Bergmayr, A., Mayerhofer, T., Troya, J., and

Wimmer, M. (2015). Xmltext: from xml schema to

xtext. In SLE, pages 71–76.

Nordmann, A., Hochgeschwender, N., and Wrede, S.

(2014). A survey on domain-speciﬁc languages in

robotics. In SIMPAR, pages 195–206. Springer.

Python Community (2022). Python homepage. https:

//www.python.org/. Last accessed Nov 2022.

Rodchenkov, M. (2019). Xenia metamodel.

https://github.com/rodchenk/xenia/blob/master/

com.foliage.xenia/model/generated/Xenia.ecore, Last

accessed Nov 2022.

Rodchenkov, M. (2020). Xenia homepage. https://github.

com/rodchenk/xenia/, Last accessed Nov 2022.

Sredojevi

c, D., Okanovi

c, D., Vidakovi

c, M., Mitrovi

c, D.,

and Ivanovi

c, M. (2015). Domain speciﬁc agent-

oriented programming language based on the xtext

framework. In ICIST, pages 8–11.

Steinberg, D., Budinsky, F., Merks, E., and Paternostro, M.

(2008). EMF: eclipse modeling framework. Pearson

Education.

Creating Python-Style Domain Speciﬁc Languages: A Semi-Automated Approach and Intermediate Results

217