MELT - a Translated Domain Specific Language Embedded in the GCC Compiler

The GCC free compiler is a very large software, compiling source in several languages for many targets on various systems. It can be extended by plugins, which may take advantage of its power to provide extra specific functionality (warnings, optimizations, source refactoring or navigation) by processing various GCC internal representations (Gimple, Tree, ...). Writing plugins in C is a complex and time-consuming task, but customizing GCC by using an existing scripting language inside is impractical. We describe MELT, a specific Lisp-like DSL which fits well into existing GCC technology and offers high-level features (functional, object or reflexive programming, pattern matching). MELT is translated to C fitted for GCC internals and provides various features to facilitate this. This work shows that even huge, legacy, software can be a posteriori extended by specifically tailored and translated high-level DSLs.Comment: In Proceedings DSL 2011, arXiv:1109.032

C++ Templates as Partial Evaluation

This paper explores the relationship between C++ templates and partial evaluation. Templates were designed to support generic programming, but unintentionally provided the ability to perform compile-time computations and code generation. These features are completely accidental, and as a result their syntax is awkward. By recasting these features in terms of partial evaluation, a much simpler syntax can be achieved. C++ may be regarded as a two-level language in which types are first-class values. Template instantiation resembles an offline partial evaluator. This paper describes preliminary work toward a single mechanism based on Partial Evaluation which unifies generic programming, compile-time computation and code generation. The language Catat is introduced to illustrate these ideas.Comment: 13 page

Language design for a personal learning environment design language

Approaching technology-enhanced learning from the perspective of a learner, we foster the idea of learning environment design, learner interactions, and tool interoperability. In this paper, we shortly summarize the motivation for our personal learning environment approach and describe the development of a domain-specific language for this purpose as well as its realization in practice. Consequently, we examine our learning environment design language according to its lexis and syntax, the semantics behind it, and pragmatical aspects within a first prototypic implementation. Finally, we discuss strengths, problematic aspects, and open issues of our approach

Development of a custom scripting language and a custom scripting system

The problem being addressed by this particular project lies in programming territory. The learning curve of programming effectively at a professional level is excruciatingly steep, in big part due to the complexity of the environment programmers work in. This environment involves both hardware and software, each with its own unique set of specifications and protocols that need to be learned in order to be effective. The general objectives that have been set are learning how to single-handedly manage a project from start to finish successfully and testing all the skills learned through the course of the degree, delivering at the end of this project a fully-functional product. The scope only considers developing a functional scripting language prototype featuring all the base, and only the base, functionalities expected of a state-of-the-art language. This decision has been made taking in consideration to the fact that a commercial product of the same type requires an amount of work that is unfeasible for a four-month project with only a single developer in charge. The methodology chosen to be applied for this project is the Iterative Model (SDLC model). This means that the project has been developed in cycles, after which the product has expanded and become more complex. Tool-wise, Visual Studio has been chosen as the main IDE and the project has been developed in C. The end result of this project is, on one hand, an Interpreter prototype that closely follows the clox implementation that is proposed in Crafting Interpreters and that can be fed one line of source code at a time and outputs the corresponding operations and on the other hand a Scripting System that can read Script Files and execute the code within. With the completion of the project, it has been concluded that the product has significant potential as a learning tool to deepen one’s understanding of programming and programming languages alike. For those interested in the inner workings of this project and its result, the links to the repositories can be found in the Links section

JVM-hosted languages: They talk the talk, but do they walk the walk?

The rapid adoption of non-Java JVM languages is impressive: major international corporations are staking critical parts of their software infrastructure on components built from languages such as Scala and Clojure. However with the possible exception of Scala, there has been little academic consideration and characterization of these languages to date. In this paper, we examine four nonJava JVM languages and use exploratory data analysis techniques to investigate differences in their dynamic behavior compared to Java. We analyse a variety of programs and levels of behavior to draw distinctions between the different programming languages. We briefly discuss the implications of our findings for improving the performance of JIT compilation and garbage collection on the JVM platform