Bx Examples Repository
Title: Language Editor Migration
Version: 0.1
Type: Industrial, Sketch
Overview
A language editor supports creating and manipulating elements of a (modelling) language.
The supported concrete syntax might be textual, visual, etc. A common challenge in practice is migrating from one language editor to another.
Reasons might be a new, (hopefully) better framework with which the new editor was developed, major changes in the syntax, or other general reasons for a migration (e.g., the old editor might have become too costly to maintain). This might sound very unidirectional, but editing tends to entail both parsing (mandatory) and serialising or pretty printing (sometimes optional). When migrating to a new editor, however, the serialiser component becomes much more useful, and arguments for viewing an editor as a bx become clearer.
As migration is often implemented by establishing a common high-level representation, language editor migration leads to multiple models that have to be kept consistent while the editors are being used. How this is to be done depends on how the editors are to be used. Can the old editor be simply thrown away after the migration? Or do we have users who do not want to migrate and still have to collaborate with others who have migrated? Can this collaboration be controlled by locking the artefacts? Or are concurrent changes unavoidable?
Each case yields a multx that can be decomposed into a network of models connected by bxs, with multiple strategies of restoring consistency in the network when one or multiple artefacts change.
Models
The models involved comprise at least:
- The legacy artefact (manipulated with the old editor)
- The new artefact (manipulated with the new editor)
- A common high-level representation of both artefacts (let's call this the "model" in this context), often used as input for some backend (compiler, type checker, etc).
Consistency
Each editor is expected to have a serialiser and parser, which can be viewed together as a bx. The interesting consistency relation here is that between the legacy and new artefact. They are of course expected to both parse to the same model in the context of a migration process, but this is not enough in practice. There are often additional conditions over both artefacts that do not involve the model. Examples include layout, decomposition into folders and files, ordering of statements, comments, and style of formatting. While inconsistencies of this kind might not affect the backend (i.e., all typical unit tests will pass), users will reject the migrated artefacts if such inconsistencies are not appropriately taken into account. Imagine migrating from one artefact with a decade's worth of comments, careful structuring into multiple folders and files, and a helpful ordering of statements, to a new artefact that is equivalent with respect to the backend, but is in just one huge file with no comments and all statements ordered alphabetically. This would be unacceptable to users.
Consistency Restoration
Explain in which of the typically many possible ways inconsistencies are to be repaired. May be divided into separate descriptions of forward and backward restoration.
Properties [optional section]
What additional properties are expected to hold of, or be exemplified by, the transformation? These will link to a separate glossary of definitions of terms such as ‘hippocraticness’.
Variants [optional section]
A difficult issue that we have found arises in writing examples is how to handle the choice points. Typically in making an example, even a small one, precise, one realises that there are several points where more than one choice is reasonable. These multiply to give a potentially unmanageable set of examples. Our proposal is that one “base” example should be given in the main body of the text, and variation points described here.
Discussion
Using the development of the MDE tool eMoflon over the years as a real-world example involving multiple migrations to new language editors, Yigitbas et al. [1] describe and discuss various patterns that can be used to handle the different scenarios and requirements involved in language editor migration.
References [optional section]
Bibliographic data for the paper or papers from which the example is taken, or where it is discussed, if applicable.
Author(s)
Anthony Anjorin
Reviewer(s)
We intend that examples remain provisional (version 0.x) until reviewed (and approved, if necessary after modification) by other members of the wiki. In the interest of traceability and credit, such reviewers are identified here.
Comments
This is where any member of the wiki can comment.
Artefacts [optional section]
Formal descriptions, perhaps downloadable code, example inputs and outputs, virtual machine instances, diagrams…
