StaDyn

Dynamic Languages

Dynamic languages like Python, Ruby, Lua, Dylan or Groovy are increasingly popular for developing different kinds of applications. These languages build on the Smalltalk idea of supporting reasoning about (and customizing) program structure, behaviour and environment at runtime. Different examples are the success of the Ruby on Rails framework for creating database-backed web systems and the use of JavaScript in both the front- and back-end of web applications; the invokedynamic opcode added to the Java Virtual Machine to support the implementation of dynamically-typed object-oriented languages; the dynamic type provided by C#; and the Dynamic Language Runtime (DLR) included in the .Net platform to facilitate the implementation of dynamic languages.

Outline

A language is said to be safe if it produces no execution errors that go unnoticed and later cause arbitrary behaviour. Static typed languages ensure the safety of programs by their type systems. However, these type systems do not compile some expressions that would have a correct behaviour at runtime. An example is to pass a message called m to an object that implements that message, but its static type does not support that message (e.g., Object). This happens because static type systems aim to make compilable programs not behave erroneously at runtime. Sometimes, it causes programs with correct behaviour not to be compilable. Figure 1 illustrates this situation (green area outside the red one).

The approach of dynamic languages is totally different. Instead of compiling programs without erroneous behaviour, they make all syntactically valid programs compilable (Figure 2). This is a too optimistic approach that causes many runtime errors that might have been detected at compile time.

The StaDyn programming language performs type checking and type inference at compile type of dynamically typed code, minimizing the compilable and wrong behaviour region of dynamic languages (Figure 2) and the not compilable and correct behaviour area of static languages (Figure 1). Both static and dynamic typing approaches can be used in the very same programming language, letting the programmer move from an optimistic (dynamic) approach to a more pessimistic, robust and efficient (static) one.

Objectives and Benefits

The StaDyn programming language has been created to follow the next objectives:

Runtime Performance

The type information gathered by the StaDyn compiler is used to optimize the runtime performance of the generated code. These optimizations are based on getting rid of many type checking operations undertaken at runtime for dynamically typed code.

Type Safety

The programmer may use statically typed references (both explicitly and implicitly typed) for those references that require the type safety of the statically typed type system. Type checking of dynamically typed code is safer than existing dynamically typed languages, because they do not perform type checking at compile time.

Flexibility

Flow sensitive types can be safely used in StaDyn. Moreover, it is also possible to safely use references with different types in the same scope. StaDyn provides statically typed duck typing.

Language Interoperability

StaDyn allows the interoperability between dynamic and static typing code. The generated code can be used as a software component. Although dynamically typed code is sometimes replaced with specialized code to obtain better performance, the original version is maintained for any other application. For that purpose, we use the services of the DLR to improve the interaction with any other language for the .Net platform.

Separation of Concerns

When the programmer wants to make parts of an application (or the whole program) more flexible (rapid prototyping of views, adaptive code, web engineering or interactive development) they could specify that in separate files of passing command-line arguments to the compiler. It is not necessary to modify the source code.

This separation of the dynamism concern promotes the transition from agile and rapid-prototyping software development to robust, safer and more efficient code.

Simplicity

The StaDyn type reconstruction (inference) system uses parametric polymorphism and type constraints to support static type checking without type annotations. The programmer does not have to explicitly specify type variables (generics) and type constraints (bounded polymorphism). The compiler will extract all this information at compile time.