This paper describes a practical approach for implementing domain-specific languages with extensible compilers. Given a compiler with one or more front-end languages, we introduce the idea of a "generic" front-end that allows the syntactic and semantic specification of domainspecific languages. Phobos, our generic front-end, offers modular language specification, allowing the programmer to define new syntax and semantics incrementally.

Many tools have been constructed using di#erent formal methods to process various parts of a language specification (e.g., scanner generators, parser generators and compiler generators). The automatic generation of a complete compiler was the primary goal of such systems, but researchers recognized the possibility that many other language-based tools could be generated from formal language specifications. Such tools can be generated automatically whenever they can be described by a generic fixed part that traverses the appropriate data structures generated by a specific variable part, which can be systematically derivable from the language specifications. This paper identifies generic and specific parts for various language-based tools. Several language-based tools are presented in the paper, which are automatically generated using an attribute grammar-based compiler generator called LISA. The generated tools that are described in the paper include editors, inspectors, debuggers and visualizers/animators. Because of their complexity of construction, special emphasis is given to visualizers/animators, and the unique contribution of our approach toward generating such tools.

Studies have shown significant benefits of the use of Domain-Specific Languages. However, designing a DSL still seems to be an art, rather than a craft following a clear methodology. In this paper, we discuss a first step towards a methodology for designing such languages. The presented approach, which is referred to as the Language-Driven Approach, is rooted in formal techniques and independent of accepted software engineering process models. We illustrate the approach with a small and instructive case study.

Abstract not found

Abstract—In some distributed and mobile communication models, a message disappears in one place and miraculously appears in another. In reality, of course, there are no miracles. A message goes from one network to another; it can be lost or corrupted in the process. Here, we present a realistic but high-level communication model where abstract communicators represent various nets and subnets. The model was originally developed in the process of specifying a particular network architecture, namely, the Universal Plug and Play architecture. But, it is general. Our contention is that every message-based distributed system, properly abstracted, gives rise to a specialization of our abstract communication model. The purpose of the abstract communication model is not to design a new kind of network; rather, it is to discover the common part of all message-based communication networks. The generality of the model has been confirmed by its successful reuse for very different distributed architectures. The model is based on distributed abstract state machines. It is implemented in the specification language AsmL and is used for testing distributed systems. Index Terms—Abstract state machines, communication protocols, computer networks, distributed systems, requirement specification, system modeling, testing of distributed systems. æ

A signature-parametric (say generic) framework for test case characterisation, and definition of test set coverage criteria is developed. The signature might correspond to a programming language syntax, the format of a data structure, a computational or semantical structure, e.g., for derivations, proof trees, or control-flow graphs. Test set characterisation is based on regular expressions describing paths for terms over the signature at hand. Necessary and convenient properties for test set coverage criteria can be conceived in the framework.

Abstract not found

Some basic programming constructs (e.g., conditional statements) are found in many di#erent programming languages, and can often be included without change when a new language is designed. When writing a semantic description of a language, however, it is usually not possible to reuse parts of previous descriptions without change. This

Usually, the majority of language constructs found in a programming language can also be found in many other languages, because language design is based on reuse. This should be reflected in the way we give semantics to programming languages. It can be achieved by making a language description consist of a collection of modules, each defining a single language construct. The description of a single language construct should be language independent, so that it can be reused in other descriptions without any changes. We call a language description framework "constructive" when it supports independent description of individual constructs. We present

Term rewriting is in the intersection of our interests and physical distance has never been large. Nonetheless we seem to be living at opposite ends of the term rewriting galaxy. Here is a story from the other side of that galaxy. Abstract. We explore the connection between term rewriting systems (TRS) and aspect-oriented programming (AOP). Term rewriting is a paradigm that is used in fields such as program transformation and theorem proving. AOP is a method for decomposing software, complementary to the usual separation into programs, classes, functions, etc. An aspect represents code that is scattered across the components of an otherwise orderly decomposed system. Using AOP, such code can be modularized into aspects and then automatically weaved into a system. Aspect weavers are available for only a handful of languages. Term rewriting can offer a method for the rapid prototyping of weavers for more languages. We explore this claim by presenting a simple weaver implemented as a TRS. We also observe that TRS can benefit from AOP. For example, their flexibility can be enhanced by factoring out hardwired code for tracing and logging rewrite rules. We explore methods for enhancing TRS with aspects and present one application: automatically connecting an interactive debugger to a language specification. 1