Welltype: Language elements for multiparadigm programming

Abstract

Abstract-Modern programming languages try to provide a balance between flexibility to support rapid development and implementing as much validation on the program as possible to avoid expensive runtime errors. This trade-off is reflected in the language syntax, the type system and even in the method how the program produces the runtime binary. While the balance seems to be slightly moved today from safety to effectiveness, there is still a high demand for thoroughly checked, safe, but still effective programming languages. In this paper we introduce our experimental, imperative programming language, Welltype, which is designed to demonstrate that effective development can be accommodated with increased safety. Our language design decisions are based on current real-life problems and their solutions. We describe key features such as syntax improvement, fail-safe type system, and binary compatibility via dynamic linking.

Detecting Binary Incompatible Software Components Using Dynamic Loader

“…The Welltype language [24,25,26] is an imperative programming language, designed to be safe: strict syntax and strong type system. While the Welltype language is safe, it is still feature rich -supports algebraic data types.…”

Towards safer programming language constructs

“…An other approach to detect the mistakes made regarding the move semantics would be to apply a Worst-case Execution Time analysis [81,82]. A proposal we made is published in [9].…”

“…The Welltype language [6,10,11] is an imperative programming language, designed to be safe: strict syntax and strong type system. While the Welltype language is safe, it is still feature rich -supports algebraic data types.…”

“…The counter-assertions, which fail on evaluation, can be seen in Fig- static _ assert(! (pair() < pair()), "OK"); static _ assert(pair() < pair(1, 0), "OK"); static _ assert(pair(2, 5) < pair(5, 2), "OK"); static _ assert(pair(2, 5) < pair (2,6), "OK"); Using this technique, any test cases can be written inside the source code, and the compiler will evaluate them during the compilation. Furthermore, using the constexpr is a good practice, since the pure functions can be validated.…”

“…The latest instruction set uses 16-bit instructions that can be extended to "double instructions" (which are 32 bits in total). The documentation of the complete instruction set can be downloaded from the official site [10,11].…”