Anthony M. Sloane

Bio: Anthony M. Sloane is an academic researcher from Macquarie University. The author has contributed to research in topics: Compiler & Attribute grammar. The author has an hindex of 13, co-authored 50 publications receiving 2426 citations. Previous affiliations of Anthony M. Sloane include University of Colorado Boulder & Delft University of Technology.

When and how to develop domain-specific languages

Abstract: Domain-specific languages (DSLs) are languages tailored to a specific application domain. They offer substantial gains in expressiveness and ease of use compared with general-purpose programming languages in their domain of application. DSL development is hard, requiring both domain knowledge and language development expertise. Few people have both. Not surprisingly, the decision to develop a DSL is often postponed indefinitely, if considered at all, and most DSLs never get beyond the application library stage.Although many articles have been written on the development of particular DSLs, there is very limited literature on DSL development methodologies and many questions remain regarding when and how to develop a DSL. To aid the DSL developer, we identify patterns in the decision, analysis, design, and implementation phases of DSL development. Our patterns improve and extend earlier work on DSL design patterns. We also discuss domain analysis tools and language development systems that may help to speed up DSL development. Finally, we present a number of open problems.

Eli: a complete, flexible compiler construction system

Abstract: William 111. Waite ver the past five years, our group has developed the Eli’ system to reduce the cost of producing compilers. Eli has been used to construct complete compilers for standard programming languages extensions to standard programming languages, and specialpurpose languages. For the remainder of this article, we will use the term compiler when referring to language processors. One of the most important ways to enhance productivity in software engineering is to provide more appropriate descriptions of problems and their

Lightweight language processing in Kiama

Abstract: Kiama is a lightweight language processing library for the Scala programming language. It provides Scala programmers with embedded domain-specific languages for attribute grammars and strategybased term rewriting. This paper provides an introduction to the use of Kiama to solve typical language processing problems by developing analysers and evaluators for a simply-typed lambda calculus. The embeddings of the attribute grammar and rewriting processing paradigms both rely on pattern matching from the base language and each add a simple functional interface that hides details such as attribute caching, circularity checking and strategy representation. The similarities between embeddings for the two processing paradigms show that they have more in common than is usually realised

When and how to develop domain-specific languages

Abstract: Domain-specific languages (DSLs) are languages tailored to a specific application domain. They offer substantial gains in expressiveness and ease of use compared with general purpose programming languages in their domain of application. DSL development is hard, requiring both domain knowledge and language development expertise. Few people have both. Not surprisingly, the decision to develop a DSL is often postponed indefinitely, if considered at all, and most DSLs never get beyond the application library stage. While many articles have been written on the development of particular DSLs, there is very limited literature on DSL development methodologies and many questions remain regarding when and how to develop a DSL. To aid the DSL developer, we identify patterns in the decision, analysis, design, and implementation phases of DSL development. Our patterns try to improve on and extend earlier work on DSL design patterns, in particular by Spinellis (2001). We also discuss domain analysis tools and language development systems that may help to speed up DSL development. Finally, we state a number of open problems.

Beyond traditional program slicing

Abstract: Traditional program slices are based on variables and statements. Slices consist of statements that potentially affect (or are affected by) the value of a particular variable at a given statement. Two assumptions are implicit in this definition: 1) that variables and statements are concepts of the programming language in which the program is written, and 2) that slices consist solely of statements.Generalised slicing is an extension of traditional slicing where variables are replaced by arbitrary named program entities and statements by arbitrary program constructs. A model of generalised slicing is presented that allows the essence of any slicing tool to be reduced to a node marking process operating on a program syntax tree. Slicing tools can thus be implemented in a straight-forward way using tree-based techniques such as attribute grammars.A variety of useful program decompositions are shown to be instances of generalised slicing including: call graph generation, interface extraction, slicing of object-oriented inheritance hierarchies and slices based on type dependences. Examples are also given of how slicing can enhance understanding of formal compiler specifications and aid the creation of subset language specifications.

When and how to develop domain-specific languages

Abstract: Domain-specific languages (DSLs) are languages tailored to a specific application domain. They offer substantial gains in expressiveness and ease of use compared with general-purpose programming languages in their domain of application. DSL development is hard, requiring both domain knowledge and language development expertise. Few people have both. Not surprisingly, the decision to develop a DSL is often postponed indefinitely, if considered at all, and most DSLs never get beyond the application library stage.Although many articles have been written on the development of particular DSLs, there is very limited literature on DSL development methodologies and many questions remain regarding when and how to develop a DSL. To aid the DSL developer, we identify patterns in the decision, analysis, design, and implementation phases of DSL development. Our patterns improve and extend earlier work on DSL design patterns. We also discuss domain analysis tools and language development systems that may help to speed up DSL development. Finally, we present a number of open problems.

Exploration and exploitation in evolutionary algorithms: A survey

Abstract: “Exploration and exploitation are the two cornerstones of problem solving by search.” For more than a decade, Eiben and Schippers' advocacy for balancing between these two antagonistic cornerstones still greatly influences the research directions of evolutionary algorithms (EAs) [1998]. This article revisits nearly 100 existing works and surveys how such works have answered the advocacy. The article introduces a fresh treatment that classifies and discusses existing work within three rational aspects: (1) what and how EA components contribute to exploration and exploitation; (2) when and how exploration and exploitation are controlled; and (3) how balance between exploration and exploitation is achieved. With a more comprehensive and systematic understanding of exploration and exploitation, more research in this direction may be motivated and refined.

FORM: A feature-oriented reuse method with domain-specific reference architectures

Abstract: Systematic discovery and exploitation of commonality across related software systems is a fundamental technical requirement for achieving successful software reuse By examining a class/family of related systems and the commonality underlying those systems, it is possible to obtain a set of reference models, ie, software architectures and components needed for implementing applications in the class FORM (FeaturedOriented Reuse Method) supports development of such reusable architectures and components (through a process called the “domain engineering”) and development of applications using the domain artifacts produced from the domain engineering FORM starts with an analysis of commonality among applications in a particular domain in terms of services, operating environments, domain technologies, and implementation techniques The model constructed during the analysis is called a “feature” model, and it captures commonality as an AND/OR graph, where AND nodes indicate mandatory features and OR nodes indicate alternative features selectable for different applications Then, this model is used to define parameterized reference architectures and appropriate reusable components instantiatable during application development Architectures are defined from three different viewpoints (subsystem, process, and module) and have intimate association with the features The subsystem architecture is used to package service features and allocate them to different computers in a distributed environment Each subsystem is further decomposed into processes considering the operating environment features Modules are defined based on the features on domain technology and implementation techniques These architecture models that represent an architecture at different levels of abstraction are derived from the feature hierarchy captured in the feature model Modules serve as basis for creating reusable components, and their specification defines how they are integrated into the application (eg, asdis integration of predcoded component, instantiation of parameterized templates, and fillingdin skeletal codes) Our experiences have shown that for the electronic bulletin board and the private branch exchange (PBX) domains, “features” make up for a common domain language and the main communication medium among application users and developers Thus, the feature model well represents a “decision space” of software development, and is a good starting point for identifying candidate reusable components