The GRL has already seen use as a host language for design patterns—see Chapter 2 §2.5.4. With these approaches there is a hard disconnect between the concepts of the design pattern and their interpretation into the constructs of the host language. The domain modelling occurs directly within the host language itself.
When using the GRL as a DSML the resulting model instances will also be a valid GRL instance, however, not all GRL concepts may be used. When using graphical languages, the modeller has to provide a mapping between the syntax and semantics of the host and domain languages. This mapping is provided through a legend, however, the onus is now on the users to ensure correct usage of the host language to model domain concepts.
DSMLs are modelling languages in name only. Although, modellers can utilise existing tooling of the host language to verify the correctness and structure of the resulting model, verification of the DSML is harder to achieve. DSML users themselves have to provide the guarantees over the correctness and structure of their model for their domain in the host language by verifying the correctness of the interpretation of their model into the host language, not to mention correctness of the evaluation semantics.
Moreover, the modeller is free to use the remaining GRL concepts such as cor- relation links, XOR decomposition or resource and soft goals in their model. How these unused concepts will relate to the modelled domain will not be known, nor is the effect that these untranslated concepts will have when determining goal satisfaction. Further, the translation of concepts from the GRL into the modelled domain must be performed manually by the user.
Finally, visual modelling languages such as GRL are typically presented as stan- dalone programs and their modelling capabilities cannot be used in other programs. For example, the known implementation of the GRL is tied to the Eclipse modelling plat- form and is provided ‘as is’. The GRL cannot be used ‘as-a-library’ and functionality to work with models outside of model evaluation does not exist.
3.8. Summary
3.8
Summary
The GRL is a modelling language for reasoning about socio-technical problems. DSMLs are custom modelling languages designed to model a particular domain but use an existing modelling language for semantic (and structural) concepts.
The GRL is one such GOML, however, the GRL is not suitable for acting as the host language for a DSML. The pictorial syntax of the DSML makes formal reasoning about GRL derived constructs a harder, and also distinct, process. With the GRL not only is there a hard disconnect between host and domain language but also the ability to use these models elsewhere is missing.
To address the concerns of designing DSMLs from the GRL, NovoGRL was created. NovoGRL is a language oriented re-engineering of the GRL and is designed as an EDSL within the dependently typed language Idris. Further, NovoGRL also allows for the semantic concepts of the GRL to be re-described for different domains. With the creation of NovoGRL comes the ability to construct DSMLs. NovoGRL was used as the host language for Sif, a DSML for design patterns. Sif has been presented as bespoke tool offering a DSL for modelling design patterns.
C
h
a
p
t
e
r
4
Dependent Types & Well-Typed
(Abstract) Interpreters
Programming language theory is the study of how programming languages are created, and provides formal methodologies for reasoning and working with these languages. One of the ideas presented in this thesis is that (programming) language oriented approaches provide for better foundations for the creation and application of both GOMLs, and the use of these languages as a host language for DSMLs.
Programming languages offer a means to encode and represent instructions that a computer can follow. These languages can be modelled formally using a variety of techniques. Abstract Syntaxto describe language expressions and statements;type- systemsto govern construction of well-formed expressions; andsemanticsto ensure
correct interpretation/execution of expressions. This chapter introduces these concepts through consideration of a simple language Arith for integer arithmetic and boolean algebra. Part of the material presented in this section is inspired by and adapted from an excellent blog postCrash Course on Notation in Programming Language Theoryby
Siek [Sie12].
Further, this chapter also details several styles of construction used within this thesis for the construction of Sif and NovoGRL. Most notably this chapter introduces the reader to dependent types, a programming language construct that allows for software programs to be reasoned on with greater precision.
4. Well-Typed (Abstract) Interpreters
Note. This chapter provides a comprehensive overview of the technical background required for this thesis, and targeted at those not familiar with programming language design, dependent types, and working at the type level. It is recommended that for those already experienced with programming language design and not with depend- ent types, should jump to §4.5. For those already experienced with dependent types, you should jump to §4.6.
4.1
The Arith Language
Through-out this chapter the formal description and implementation of a simple language, Arith will be considered. This language extends the language specified in Siek [Sie12]. The Arith language allows for the specification of expressions that describe either integer arithmetic or boolean algebra. The supported operators are for:
• Integer Arithmetic: Addition, subtraction, multiplication, and division. • Boolean Algebra: Conjunction, disjunction, and negation.
The next section, §4.2, describes how thesyntaxof Arith is described more formally.
§4.3 describes how well-formed Arith expressions are detailed and reasoned on using types. The remaining sections detail the construction of an interpreter for Arith and how dependent types provide correctness guarantees towards the interpreters implementation.