Building Your Own DSL with Xtext

Editor's Notes

• #4: Zaczynamy. Na poczatek któtkie wprowadzenie do języków dziedzinowych czyli skupiajcych się na specyficznym problemie. Zanim rozpocznę o Xtext wprowadzę czym jest EMF – framework używany przez Xtext Powiem w kilku słowach czym jest Xtext w kontekście tworzenia języka. Następnie kilka słów o gramatyce oraz Jak Xtext ma się do EMFa Potem przejdziemy do demonstracji podstawowych elementów Xtext-a (takich jak formatowanie, generowanie nowych artefaktów, scoping, walidacja, content assist czy quick-fix,) Na koniec powiem o nowościach w Xtext 2.9
• #7: This is an Eclipse project conducted mainly by itemis, started about 2008. Current version is 2.9. 2.9 in was released Nov 16, 2015 and it covers some new areas which I will try to show you later on. Behind the xtext is an ANTLR3 (ANother Tool for Language Recognition) as parser generator, EMF as the foundation of the model classes and google guice for dependency injection. Xtext is a language development framework – you can pick only those elements you want. - Provides API for configuring and describing elements of DSL Xtext components are independent of Eclipse and OSGi In 2.9 this distinction is better visible as you can pick project facets (IntelliJ plugins, Web support, Testing support, maven / grable build system, source code layout) – in 2.8 this separation is achievable but needs to be done manually. What does it contain? Parser – translates the string input into EMF model Abstract syntax tree – represents elements of your DSL in form of a tree Serializer – writing your EMF model back to textual form Code formatter – rules for formatting Scoping framework and linking. Eclipse – mature IntelliJ IDEA – new features I’will not cover binding to Java using Xbase. In general it allows using syntax which is close to java in your grammars.
• #8: Xtext grammar is defined using its DSL. This file is then used by generator to create all language artifacts. Xtext uses Antlr under the hood in order to do the pure parsing. This is basically a two step process: At first, the input sequence of characters is split into tokens (often referred to as terminals) by a component that is called the lexer. The second step is to process the resulting list of tokens. The actual parser is responsible for that stage. It will create the abstract syntax tree from the token stream. Lexing – terminal rules (be careful, overrides the other, can be validated) Parsing – generates AST items Parser rules (production rules) – generated EClass Data type rules – generates Java primitives - The parser will not create those on its own but rather pass the consumed tokens as a string to a value converter. The language developer is responsible for converting the string to a data type. Terminal rules - an return the very same things as data type rules can. That is, they yield Strings, ints or other primitives Doesn’t have look ahead but is more performant Order matters
• #10: Release candidate http://download.eclipse.org/modeling/tmf/xtext/idea/2.9.2/updatePlugins.xml - It’s it possible to design languages entirely in IDEA - Languages developed in Eclipse can target all available platforms (Eclipse, IDEA, web). It doesn’t worh the outer way round as IDEA is not well suited for Eclipse Plug-in devlelopment. Eclipse support is not going to be dropped Builds with Maven / Gradle You can select the elements (language / editor / build system during project generation). Web editors can be generated New grammar features Explicit rule calls – allows to use rules definitions from parent grammars without the need for redefining Parser rule fragments – allows to reuse common parts of the grammar Parameterized rule calls – lack of documentation, don’t have an idea where it would help