Modular extensions for modular (Logic) languages

We address the problem of developing mechanisms for easily implementing modular extensions to modular (logic) languages. By(language) extensions we refer to different groups of syntactic definitions and translation rules that extend a language. Our use of the concept of modularity in this context is twofold. We would like these extensions to be modular, in the sense above, i.e., we should be able to develop different extensions mostly separately. At the same time, the sources and targets for the extensions are modular languages, i.e., such extensions may take as input sepárate pieces of code and also produce sepárate pieces of code. Dealing with this double requirement involves interesting challenges to ensure that modularity is not broken: first, combinations of extensions (as if they were a single extensión) must be given a precise meaning. Also, the sepárate translation of múltiple sources (as if they were a single source) must be feasible. We present a detailed description of a code expansion-based framework that proposes novel solutions for these problems. We argüe that the approach, while implemented for Ciao, can be adapted for other Prolog-based systems and languages.

Towards modular extensions for a modular language

Modularity allows the construction of complex designs from simpler, independent units that most of the time can be developed separately. In this paper we are concerned with developing mechanisms for easily implementing modular extensions to modular (logic) languages. By (language) extensions we refer to different groups of syntactic definitions and translation rules that extend a language. Our application of the concept of modularity in this context is twofold. We would like these extensions to be modular, in the above sense, i.e., we should be able to develop different extensions mostly separately. At the same time, the sources and targets for the extensions are modular languages, i.e., such extensions may take as input separate pieces of code and also produce separate pieces of code. Dealing with this double requirement involves interesting challenges to ensure that modularity is not broken: first, combinations of extensions (as if they were a single extension) must be given a precise meaning. Also, the separate translation of multiple sources (as if they were a single source) must be feasible. We present a detailed description of a code expansion-based framework that proposes novel solutions for these problems. We argue that the approach, while implemented for Ciao, can be adapted for other languages and Prolog-based systems.

Reversible language extensions and their application in debugging

A range of methodologies and techniques are available to guide the design and implementation of language extensions and domainspecific languages. A simple yet powerful technique is based on source-tosource transformations interleaved across the compilation passes of a base language. Despite being a successful approach, it has the main drawback that the input source code is lost in the process. When considering the whole workflow of program development (warning and error reporting, debugging, or even program analysis), program translations are no more powerful than a glorified macro language. In this paper, we propose an augmented approach to language extensions for Prolog, where symbolic annotations are included in the target program. These annotations allow selectively reversing the translated code. We illustrate the approach by showing that coupling it with minimal extensions to a generic Prolog debugger allows us to provide users with a familiar, source-level view during the debugging of programs which use a variety of language extensions, such as functional notation, DCGs, or CLP{Q,R}.

Efficiency and spatial equity impacts of high-speed rail extensions in urban areas

Urban areas benefit from significant improvements in accessibility when a new high speed rail (HSR) project is built. These improvements, which are due mainly to a rise in efficiency, produce locational advantagesand increase the attractiveness of these cities, thereby possibly enhancing their competitivenessand economic growth. However, there may be equity issues at stake, as the main accessibility benefits are primarily concentrated in urban areas with a HSR station, whereas other locations obtain only limited benefits. HSR extensions may contribute to an increase in spatial imbalance and lead to more polarized patterns of spatial development. Procedures for assessing the spatial impacts of HSR must therefore follow a twofold approach which addresses issues of both efficiency and equity. This analysis can be made by jointly assessing both the magnitude and distribution of the accessibility improvements deriving from a HSR project. This paper describes an assessment methodology for HSR projects which follows this twofold approach. The procedure uses spatial impact analysis techniques and is based on the computation of accessibility indicators, supported by a Geographical Information System (GIS). Efficiency impacts are assessed in terms of the improvements in accessibility resulting from the HSR project, with a focus on major urban areas; and spatial equity implications are derived from changes in the distribution of accessibility values among these urban agglomerations.

Heavyweight extensions to the UML metamodel to describe the C3 architectural style

UML is widely accepted as the standard for representing the various software artifacts generated by a development process. For this reason, there have been attempts to use this language to represent the software architecture of systems as well. Unfortunately, these attempts have ended in the same representations (boxes and lines) already criticized by the software architecture community.In this work we propose an extension to the UML metamodel that is able to represent the syntactics and semantics of the C3 architectural style. This style is derived from C2. The modifications to define C3 are described in section 4. This proposal is innovative regarding UML extensions for software architectures, since previous proposals where based on light extensions to the UML meta-model, while we propose a heavyweight extension of the metamodel. On the other hand, this proposal is less ambitious than previous proposals, since we do not want to represent in UML any architectural style, but only one: C3.