One data fragment has several alternative structural representations tailored toward specic data manipulation approaches. Concrete Syntax and Abstract Syntax simplifying concrete syntax to abstract syntax [20, 58] parsing [44], more than parsing [24, 30], parsing in a broad sense [61] object grammars [52] Interparadigmatic Data Binding COBOL OO Relational databases XML [35] OO Relational [13] CRUD OO [49] XML Data Binding XML to Java [37] XML to Haskell [6] XML to C# [38] GUI Data Binding generic GUIs [1] WebSocket-based data binding [23] Intermediate Representation support imperative and declarative idioms [34] multiple languages within one paradigm: FP [27], OO [11] implementation-geared [5, 42] validation-geared [9] and analysis-geared [22, 31] Views integrated personalised views in databases [48] model views [3, 4, 10] view-based software engineering [7, 46] architectural views [15, 51, 59]
When modelling or programming, people tend to think in terms of conceptual constructs: inheritance (of classes), conformance (of models to metamodels), conditional statement (programming), input (data ow, side eects) and others. In practice these conceptual entities are represented as concrete elements: in textual form, in graphical diagrams, in memory blocks, etc. Since the actual solution has to be expressed in such elements, this notation exposed to the language end user, has great impact on the eectiveness of both the solution and the process of modelling or programming.
Results from ontological analysis tell us that a mapping between a modelling
notation and an underlying domain model (in SE usually the
Bunge-WandWeber ontology [
Construct redundancy : when one conceptual entity can be modelled with
more than one notational construct that are identical or subtly dierent
from one another. Notations with construct overloaded are called unclear
and are advocated by ontological analysts to be defective. Construct
redundancy in programming languages often leads to discussions of taste and
conventions being imposed on top of the language. For example, a
functional language called Haskell [
Construct overload : when one notational entity represents several conceptual entities. Notations with this smell are a dierent kind of unclear : they are merely slightly counter-intuitive to domain experts but give wrong impressions to those who learn the domain through this notation. A famous example nowadays is the Git version control framework that bundles unrelated functionality: for instance, git reset is a command that, depending on parameters, can simply unstage code changes (which means they will not be included in the next commit) or undo several unpushed commits or even irrecoverably wipe any pending changes away.
Construct excess is said to happen when a modelling notation have elements that do not have any correspondence in the domain model. Notations frequently have construct excesses as practical shortcuts and quick hacks that solve the problem at hand but are totally alien to the uninvolved domain experts. Excessive constructs are never designed into a notation but nd their way into it by the time of implementation, especially under deadline pressure.
Success stories from updatable views in databases [
You design a software language and must provide functionality in the entire spectrum from parsing the textual input to advanced semantic consistency validation like type checking.
If you make your grammar too close to the desired conceptual
representation, you risk making it ambiguous, inecient for parsing and/or not
user friendly for the language users. Projectional language workbenches
deliberately choose this path due to their naturally powerful IDE
support [
If you make it too close to the desired way of writing and reading
sentences in the language, you risk overburdening your traversals and
rewritings with unnecessary details concerning a particular textual
representation. Solutions without multiple faces usually include
conventions that allow to use one representation to mean multiple things at
once [
You want your software language to have both textual and visual concrete syntax which are conceptually the same but technically get a dierent representation each. Due to the natural ow of the textual representation (usually left to right, character by character) and a much freer structure of the visual syntax, elements that correspond to the same entities may not only be represented dierently individually, but also appear in dierent order.
The need for several notations of one domain-specic language is widely
known and acknowledged in practice [
In general textual information is perceived by humans to be more
trustworthy [
Structured data that you are working with, needs to be serialised for storage, communication or backup.
Using the existing textual syntax would mean losing the structure and may imply future overhead and/or ambiguity in deserialising such data. In practice people tend to develop a yet another format which conceptually represents the same structure of the same data, but is more suitable for marshalling and unmarshalling. Such a format can be a standalone project but usually is a sublanguage of XML or JSON.
The same language (yellow box on the megamodel) can be dened by dierent, possibly incomplete, metamodels, and thus the models that conform to them, correspond to the same language instances, but belong to dierent technological stacks and thus can be eectively used with dierent algorithms. Functions Fk are used in a broad sense and can represent true functions like sorting or traversals, as well as other data manipulation activities such as editing or validation.
One of the faces can be dominant within a domain for historical reasons and
so advanced that over the time it developed all necessary algorithms usually
associated with other faces e.g., concrete syntax in metaprogramming [
In scenarios with more than two faces it gets too complex to develop direct mappings for each pair; in that case it is better to consider a star-shaped infrastructure with one canonic representation which is capable of synchronising with any of the other ones.
When metamodels are well-dened and their dierences are explicitly
expressed, we can do coupled transformations [
It denes a piece of very simple abstract data type with two constructors. The metaprogramming facilities provided by Rascal allow us to comfortably traverse instances structured in such a way and perform computations: visit(T) { visit(T) { } } foo(True) : cx += 1 bar(_) => foo(False) (even more concise, len([1 | /foo(True) := T]) ), and in place rewritings:
However, writing them to a le can only be done in one xed notation, and reading back will not be smooth. For such actions, we need concrete syntax for example, this one: syntax A = foo: "FOO"? | bar: "<" {A ":"}+ ">";
Parsing any textual input with this concrete syntax denition is trivial in Rascal with the use of parse(#A, ...) function. The resulting trees, however, are somewhat clunky, contain too much information (who cares that we used colons as a separator? should we really update the traversal code if the separator changes in the future?) and can only be traversed in their default term form. However, there is a built-in matching function called implode that can couple the two: T = implode(A, parse(#A, input))
The implode function follows grammar production alternative labels and match them to the constructors of the data type. Then, it maps the presence of FOO text to a true value and the lack of it to a false value of the Boolean argument of the foo constructor. Parse-guiding anti-ambiguity angle brackets in the concrete syntax carry no structural meaning, so they are disregarded, and the collection of inner entries is mapped to a set because that is what the abstract data type expects (it could have been mapped to a list instead).
ACM