The main objective of this project is to break the programmers' black or white choice between static or dynamic typing. StaDyn is a programming language that offers both dynamic and static typing following the Separation of Concerns principle, obtain both the benefits of static typing (runtime performance, earlier type error detection, and better IDE features) and dynamic typing (flexibility, rapid prototyping, less verbose code, and dynamically adaptable).
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
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
included in the .Net platform to facilitate
the implementation of dynamic languages.
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.
The StaDyn programming language has been created to follow the next objectives:
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.
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.
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.
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.
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.
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.
To see source code examples in a brief tutorial, please check out the Getting Started page.