Edoardo Vacchi

Neverlang 2 – Componentised Language Development for the JVM

Traditional compiler development is non-modular. Although syntax extension and DSL embedding is making its way back in modern language design and implementation, componentisation in compiler construction is still an overlooked matter. Neverlang is a language development framework that emphasises modularity and code reuse. Neverlang makes extension, restriction and feature sharing easier, by letting developers define language components in distinct, independent units, that can be compiled independently and shared across different language implementations, even in their compiled form. The semantics of the implemented languages can be specified using any JVM-supported language. In this paper we will present the architecture and implementation of Neverlang 2, by the help of an example inspired by mobile devices and context-dependent behaviour. The Neverlang framework is already being employed successfully in real-world environments.

Variability Support in Domain-Specific Language Development

Domain Specific Languages (DSLs) are widely adopted to capitalize on business domain experiences. Consequently, DSL development is becoming a recurring activity. Unfortunately, even though it has its benefits, language development is a complex and time-consuming task. Languages are commonly realized from scratch, even when they share some concepts and even though they could share bits of tool support. This cost can be reduced by employing modern modular programming techniques that foster code reuse. However, selecting and composing these modules is often only within the reach of a skilled DSL developer. In this paper we propose to combine modular language development and variability management, with the objective of capitalizing on existing assets. This approach explicitly models the dependencies between language components, thereby allowing a domain expert to configure a desired DSL, and automatically derive its implementation. The approach is tool supported, using Neverlang to implement language components, and the Common Variability Language (CVL) for managing the variability and automating the configuration. We will further illustrate our approach with the help of a case study, where we will implement a family of DSLs to describe state machines.

Data Extraction and Management in Networks of Observational Health Care Databases for Scientific Research: A Comparison of EU-ADR, OMOP, Mini-Sentinel and MATRICE Strategies

Introduction: We see increased use of existing observational data in order to achieve fast and transparent production of empirical evidence in health care research. Multiple databases are often used to increase power, to assess rare exposures or outcomes, or to study diverse populations. For privacy and sociological reasons, original data on individual subjects can’t be shared, requiring a distributed network approach where data processing is performed prior to data sharing. Case Descriptions and Variation Among Sites: We created a conceptual framework distinguishing three steps in local data processing: (1) data reorganization into a data structure common across the network; (2) derivation of study variables not present in original data; and (3) application of study design to transform longitudinal data into aggregated data sets for statistical analysis. We applied this framework to four case studies to identify similarities and differences in the United States and Europe: Exploring and Understanding Adverse Drug Reactions by Integrative Mining of Clinical Records and Biomedical Knowledge (EU-ADR), Observational Medical Outcomes Partnership (OMOP), the Food and Drug Administration’s (FDA’s) Mini-Sentinel, and the Italian network—the Integration of Content Management Information on the Territory of Patients with Complex Diseases or with Chronic Conditions (MATRICE). Findings: National networks (OMOP, Mini-Sentinel, MATRICE) all adopted shared procedures for local data reorganization. The multinational EU-ADR network needed locally defined procedures to reorganize its heterogeneous data into a common structure. Derivation of new data elements was centrally defined in all networks but the procedure was not shared in EU-ADR. Application of study design was a common and shared procedure in all the case studies. Computer procedures were embodied in different programming languages, including SAS, R, SQL, Java, and C++. Conclusion: Using our conceptual framework we found several areas that would benefit from research to identify optimal standards for production of empirical knowledge from existing databases.an opportunity to advance evidence-based care management. In addition, formalized CM outcomes assessment methodologies will enable us to compare CM effectiveness across health delivery settings.

Automating variability model inference for component-based language implementations

Recently, domain-specific language development has become again a topic of interest, as a means to help designing solutions to domain-specific problems. Componentized language frameworks, coupled with variability modeling, have the potential to bring language development to the masses, by simplifying the configuration of a new language from an existing set of reusable components. However, designing variability models for this purpose requires not only a good understanding of these frameworks and the way components interact, but also an adequate familiarity with the problem domain. In this paper we propose an approach to automatically infer a relevant variability model from a collection of already implemented language components, given a structured, but general representation of the domain. We describe techniques to assist users in achieving a better understanding of the relationships between language components, and find out which languages can be derived from them with respect to the given domain.

Neverlang 2: a framework for modular language implementation

Neverlang 2 is a JVM-based framework for language development that emphasizes code reuse through composition of language features. This paper is aimed at showing how to develop extensible, custom languages using Neverlangs component-based model of implementation. Using this model, each feature of the language can be implemented as a separate, conceptually isolated unit that can be compiled and distributed separately from the others. A live tutorial of the framework can be found at http://youtu.be/Szxvg7XLbXc

On the incremental growth and shrinkage of LR goto-graphs

The LR(0) goto-graph is the basis for the construction of parsers for several interesting grammar classes such as LALR and GLR. Early work has shown that even when a grammar is an extension to another, the goto-graph of the first is not necessarily a subgraph of the second. Some authors presented algorithms to grow and shrink these graphs incrementally, but the formal proof of the existence of a particular relation between a given goto-graph and a grown or shrunk counterpart seems to be still missing in literature as of today. In this paper we use the recursive projection of paths of limited length to prove the existence of one such relation, when the sets of productions are in a subset relation. We also use this relation to present two algorithms (Grow and Shrink) that transform the goto-graph of a given grammar into the goto-graph of an extension or a restriction to that grammar. We implemented these algorithms in a dynamically updatable LALR parser generator called DEXTER (the Dynamically EXTEnsible Recognizer) that we are now shipping with our current implementation of the Neverlang framework for programming language development.

Fine-grained annotations for pointcuts with a finer granularity

A number of authors have suggested that AspectJ-like pointcut languages are too limited, and that they cannot select every possible join point in a program. Many enhanced pointcut languages have been proposed; they require virtually no change to the original code, but their improved expressive power comes often at the cost of making the pointcut expression too tightly connected with the structure of the programs that are being advised. Other solutions consist in simple extensions to the base language; they require only small changes to the original code, but they frequently serve no other immediate purpose than exposing pieces of code to the weaver. Annotations are a form of metadata that has been introduced in Java 5. Annotations have a number of uses: they may provide hints to the compiler, information to code processing tools and they can be retained at runtime. At the moment of writing, runtime-accessible annotations in the Java programming language can only be applied to classes, fields and methods. The support to annotate expressions and blocks feels like a natural extension to Javas annotation model, that can be also exploited to expose join points at a finer-grained level. In this paper we present an extension to the AspectJ language to select block and expression annotations in the @Java language extension.

@Java: annotations in freedom

The ability to annotate code and, in general, the capability to attach arbitrary metadata to portions of a program are features that have become more and more common in programming languages. In fact, various programming techniques and tools exploit their explicit availability for a number of purposes, such as extracting documentation, guiding code profiling, enhancing the description of a data type, marking code for instrumentation (for instance, in aspect-oriented frameworks), and the list could go on. While support to attach metadata to code is not a new concept (programming platforms as CLOS and Smalltalk have pioneered in this field), consistent, pervasive APIs to define and manage code annotations are something comparatively recent on modern platforms like the .NET and Java. Annotations in Java make possible to attach custom, structured metadata to declarations of classes, fields and methods. With this work, we propose an extension to Java (named @Java) that has a richer annotation model, supporting code block and expression annotations. In other words, the granularity of annotations extends to the statement and expression level and does not limit to class, method and field declarations.