Recent years have seen increased interest in scripting languages, notably script to program migration/evolution and the interplay between typed and untyped code.
Scripting languages are lightweight, dynamic programming languages designed to maximize productivity by offering high-level abstractions and reducing the syntactic overhead found in most system's languages. The rising popularity of scripting languages such as Perl, Python, PHP, Tcl, JavaScript, Ruby, and Groovy have many underlying causes: they allow partial execution of programs, permitting easy unit testing, interactive experimentation, and even demoing of software at all times; their support for powerful and flexible high-level datatypes and dynamic typing admits quick interim solutions that can later be revised; etc. In short, scripting languages optimize development time rather than machine time, a good approach early in the software development life cycle.
However, once the understanding of the system has reached a critical point and requirements have stabilized, scripting languages become less appealing. The compromises made to optimize development time make it harder to reason about program correctness, harder to do semantic-preserving refactorings, and harder to optimize execution speed. The lack of type information makes the code harder to navigate.
This situation often leads to a rewrite of a program in a less dynamic language, which may be costly and may introduce many bugs due to human error or semantic differences between the scripting language and the new target language (e.g., lack of garbage collection in C++, stricter type rules in Java, differences in available libraries, etc.). Sometimes only parts of the program are reimplemented, e.g., in C or assembler, as an optimization technique for a particularly computation-intensive method. Bridging a high-level scripting language to lower-level C introduces new opportunities for errors, possibly introduces platform-specific ties, and increases the number of languages a programmer must know to maintain the system. Both these approaches, especially the first one, have the downside of slowing down future development as they effectively preclude further use of the scripting language for prototyping new features.
Recently, the concept of pluggable types has been proposed, which encourages the use of different optional type systems which do not have any effect on the run-time semantics of the programming language. It is believed that untyped scripts can be retrofitted to work with pluggable type systems (2), but with very few exceptions (i.e., Strongtalk), practical reports are yet to be found. Various ways of integrating or interfacing typed with untyped code have been proposed, like gradual typing, which allows for evolving script code to a more "safe state" more suitable for program analysis and compile-time optimisations.
The STOP workshop is interested in evolution of scripts in the sense of largely untyped pieces of code into safer programs, with more rigid structure and constrained behaviour through the use of gradual/hybrid/pluggable typing, optional contract checking, extensible languages, refactoring tools, and the like. The goal is to further the understanding of such systems in practise, and connect practise and theory.
STOP's subject areas have recently seen increased interest by several research groups, but there is no common understanding of how gradual/hybrid/pluggable typing, script to program evolution, typed to untyped evolution, etc. interplay, and there are few experience reports from extant languages that support pluggable types or optional type annotations (Cecil, CLOS, Dylan, PLT Scheme, Strongtalk, and others). This workshop aims to bring researchers together for passionate discussion about these topics, and to promote not only the theory, but practical evalution of these ideas, and experience reports.
Proceeding Downloads
Blame for all
We present a language that integrates statically and dynamically typed components, similar to the gradual types of Siek and Taha (2006), and extend it to incorporate parametric polymorphism. Our system permits a dynamically typed value to be cast to a ...
Tests to the left of me, types to the right: how not to get stuck in the middle of a ruby execution
Ruby is a popular dynamic scripting language that permits terse, expressive code, but provides no static checks to detect errors before running the program. To address this, we have developed Diamond-back Ruby (DRuby), a tool that blends the benefits of ...
Towards gradual typing for generics
Gradual typing, proposed by Siek and Taha, is a framework to combine the benefits of static and dynamic typing. Under gradual typing, some parts of the program are type-checked at compile time, and the other parts are type-checked at run time. The main ...
Understanding the dynamics of JavaScript
We report on preliminary results on understanding the nature of JavaScript programs. Our investigation is motivated by the goal of developing a type system for JavaScript programs. As a prelude, we decide to gain a better understanding of the dynamic ...
Threesomes, with and without blame
The blame calculus of Wadler and Findler gives a high-level semantics to casts in higher-order languages. The coercion calculus of Henglein, on the other hand, provides an instruction set for casts whose normal forms ensure space efficiency. In this ...
Cycles without pollution: a gradual typing poem
It is fairly intuitive that adding dynamic typing to a statically typed language can add some convenience to a developer, at the price of weakening the guarantees of the type system. Surprisingly, the reverse is also true. This paper presents a ...
Software hardening: a research agenda
This paper lays out the research agenda of the Thorn project, a collaboration between IBM Research and Purdue University with the goal of exploring how to incrementally transition rapid prototypes into robust programs. The project is in its early stages ...