Project topics and materials
Get Complete Project Material File(s) Now! »
Cognitive Distance
We use the ideas of Krueger [Krueger 1992] about cognitive distance to evaluate existing LIT solutions later in this chapter. According to Krueger, LIT success depends on the effectiveness of its abstractions, which can be evaluated in terms of cognitive distance. He defines cognitive distance as an informal and intuitive measure of the amount of intellectual effort required to accomplish software development tasks. For the creator of a software reuse technique, the goal is to minimize cognitive distance by using abstractions that are both succinct and expressive, and by using automated mappings from abstraction specification to abstraction realization. Analyzing the automatic mapping process requires taking into consideration possible errors produced during the process. An error is a combination of a defect (the cause) and a failure (the symptom). We define these concepts as follows.
Defect. Also named bug, is an unintended mistake introduced by the programmer in the source representation of a program [Beizer 1990]. Failure. Is an unwanted executional behavior that is externally observable by a developer while a process is running [Spinellis 2018]. A critical failure [Zeller 2005] is a failure that interrupts the execution of the process. Developers reason about and formulate questions using concepts and abstractions from their specification domain. Not offering a one-to-one mapping between developer questions and debugging support forces developers to refine their high-level questions into low-level ones and mentally piece together information from various sources. [Sil-lito 2008].
Language Implementation Techniques (LIT)
LIT are software reuse techniques that reduce the efforts of implementing new languages providing solutions to produce different languages with little input from developers [Big-gerstaff 1992], improving developers productivity [Frakes 2005].
LIT Evaluation Criteria
On the basis of Krueger [Krueger 1992] ideas, we propose the following criteria to evaluate cognitive distance in LIT: C1. Specification abstractions provided by the technique must be succinct, expressive, and must be close to abstractions used for conceptualization of language syntax and semantics. C2. The mapping between abstraction specification and realization must be automatic. In the case the mapping process fails, the technique should provide debugging sup-port that answers developer questions formulated at the level of their abstraction specifications.
LIT Classification
LIT can be divided according to their approach for language specification and sub-sequent mapping to realization in two groups: generation techniques and self-surgery techniques. Our classification is consistent with the classification for software reuse tech-niques proposed by Biggerstaff et al. [Biggerstaff 1987], which is based on the nature of the software components being reused.
Generation Techniques
In Generation LIT the abstraction level of specification is higher than that of realiza-tion1. The logics to transform specifications into realizations is inside the generator program. These logics are the technique’s reusable components and, in principle, they are kept hidden from the user.
As an example, we present in Listing 2.1 the specification for the semantics of the boolean operator ’not’ in DynSem [Vergu 2015], a DSL for specification of dynamic semantics which is part of the language workbench Spoofax [Metaborg ]. The semantics of ’not’ is specified as two reduction rules written in DSL code. DynSem’s interpreter generator is an application written in Java that takes these rules as input and generates the Java code that implements the specified semantics in an interpreter.
Meta-Compilation Techniques
Meta-compilers are a special kind of compiler used to construct compilers of different programming languages. They focus on language performance and support a wide variety of general purpose languages. They integrate to a self-optimizing interpreter defined by the user and infer a just-in-time compiler from it. RPython [Bolz 2009] and GraalVM [GraalVM ,Wimmer 2012,Würthinger 2017,Wimmer 2019] are popular state of the art meta-compilers.
Table of contents :
1 Introduction
1.1 Abstractions for Language Definition
1.2 Reflective Languages
1.3 Bootstrap
1.4 Problem Statement
1.5 Hypothesis
1.6 Results
1.6.1 Research Question
1.6.2 Research Question 2 and Hypothesis
1.7 Contributions
1.8 Thesis Outline
2 Language Implementation Techniques
2.1 Cognitive Distance
2.2 Language Implementation Techniques (LIT)
2.2.1 LIT Evaluation Criteria
2.2.2 LIT Classification
2.3 Generation Techniques
2.3.1 Language Workbenches
2.3.2 Meta-Compilation Techniques
2.4 Self-Surgery Techniques
2.4.1 Concepts About Reflection
2.4.2 Smalltalk Self-Surgery
2.4.3 CLOS Self-Surgery
2.4.4 Self-Surgery Limitations
2.5 LIT Evaluation
2.5.1 C1. Abstractions
2.5.2 C2. Mapping From Specifications To Realizations
2.5.3 Conclusion
2.6 Overcoming Self-Surgery Limitations: Language Runtime Initialization
2.6.1 Ruby and Python Runtime-Initialization
2.6.2 Discussion
2.7 Bootstrap
2.7.1 Common Lisp Bootstrap
2.7.2 Smalltalk Bootstrap
2.7.3 Discussion
2.8 Conclusions
3 Challenges Bootstrapping Reflective Kernels
3.1 Pharo Bootstrap
3.1.1 Pharo Bootstrap in a Nutshell
3.1.2 (A) Language Sources and Language Model (declarative)
3.1.3 (B, C) Generation Instructions (imperative)
3.1.3.1 (B) Reflective instructions
3.1.3.2 (C) Non-reflective instructions
3.2 Causes of Bootstrap Failures
3.2.1 VM Constraints on the Kernel Structure
3.2.2 Classification of Defects and Failures
3.2.2.1 Classification of Defects
3.2.2.2 Classification of Failures
3.2.3 Taxonomy of Defects and Failures
3.3 Challenges Bootstrapping ObjVLisp
3.3.1 Pharo’s Metamodel Does Not Support Explicit Metaclasses
3.3.2 Structural Def. causes VM Const. Fail at Generation (easy)
3.3.3 Structural Def. causes VM Const. Fail at Generation (hard)
3.3.4 Reflective Def. causes Guest-Lang. Code Fail at Generation
3.3.5 Reflective Def. causes VM Constraint Fail at Generation
3.3.6 Structural Def. causes VM Constraint Fail at Execution
3.3.7 Non-Reflective Def. causes VM-Constraint Fail at Execution
3.3.8 Application Def. causes Guest-Lang. Code Fail at Execution
3.4 Analysis Of Cognitive Distance In Bootstrap
3.4.1 Introduction to Cognitive Distance Representations
3.4.2 Causes Of Large Cognitive Distance In Bootstrap
3.5 Desirable Features Of A Bootstrap-Based LIT
3.5.1 Requirement 1
3.5.2 Requirement 2
3.5.3 Requirement 3
3.6 Conclusions
4 Bootstrap-Based Language Implementation: MetaL
4.1 MetaL in a Nutshell
4.2 MetaL by Example: Generating OvlispL
4.2.1 General Bootstrap Process
4.2.2 Metamodel Definition
4.2.3 Definition of Roles
4.2.4 Model Construction
4.2.4.1 Core Class-Models
4.2.4.2 Automatic Model Completion
4.2.4.3 User-Defined Model Transformations
4.2.5 Kernel Generation, Writing, and Execution
4.3 Debugging OvlispL Bootstrap in MetaL
4.3.1 Solving Structural Defects
4.3.2 Solving Reflective Defects
4.4 Kernel and Model Validations
4.4.1 Model Validations: Roles
4.4.2 Roles and Smart Mirrors
4.4.3 Kernel Validations: Smart Mirrors
4.4.4 Extending validations for a new VM
4.5 Conclusions
5 MetaL Evaluation: Bootstrapping Kernels
5.1 OvlispL slot
5.1.1 Application
5.1.2 Metamodel
5.1.3 Model
5.1.4 Discussion
5.2 ObjV Lisp
5.2.1 Application
5.2.2 Metamodel
5.2.3 Model
5.2.4 Discussion
5.3 OvlispL ns
5.3.1 Application
5.3.2 Metamodel
5.3.3 Model
5.3.4 Discussion
5.4 CandleL
5.4.1 Application
5.4.2 Metamodel
5.4.3 Model
5.4.4 Discussion
5.5 OwnerL
5.5.1 Application
5.5.2 Metamodel
5.5.3 Model
5.5.4 Kernel Initialization
5.5.5 Discussion
5.6 OvlispL dyn
5.6.1 Application
5.6.2 Metamodel
5.6.3 Model
5.6.4 Discussion
5.7 Experiment by External User
5.8 Analysis Of Cognitive Distance In MetaL
5.9 Evaluation of MetaL
5.9.1 Meeting Requirement 1
5.9.2 Meeting Requirement 2
5.9.3 Meeting Requirement 3
5.9.4 Limitations
5.10 Conclusions
6 Aspect-Oriented Bootstrap: AspectMetaL
6.1 AOP in a Nutshell
6.2 AspectMetaL Overview
6.2.1 General Process
6.2.2 AspectMetaL Aspects
6.3 AspectMetaL By Example: Generating OvlispL scv
6.3.1 Semantic Features
6.3.2 Metamodel Definition
6.3.3 Definition Of A New Aspect
6.3.4 Aspect Reuse
6.3.5 Deployment Ordering
6.4 Discussion
6.4.1 Abstractions In AspectMetaL
6.4.2 Code Reuse In AspectMetaL
6.4.3 Limitations
6.5 Conclusions
7 Conclusions
7.1 Contributions
7.1.1 MetaL
7.1.2 AspectMetaL
7.1.3 Research Questions & Hypotheses
7.2 Future Work
A Associated Publications
A.1 Journals
A.2 Conferences
A.3 Workshops
A.4 Vulgarization
B MetaL MOP
C MetaL Roles
D Aspect-Oriented Programming (AOP)
D.1 AOP Concepts
D.2 PHANtom
Bibliography
