Type-safe run-time polytypic programming

2006 ◽  
Vol 16 (6) ◽  
pp. 681-710 ◽  
Author(s):  
STEPHANIE WEIRICH

Polytypic programming is a way of defining type-indexed operations, such as map, fold and zip, based on type information. Run-time polytypic programming allows that type information to be dynamically computed – this support is essential in modern programming languages that support separate compilation, first-class type abstraction, or polymorphic recursion. However, in previous work we defined run-time polytypic programming with a type-passing semantics. Although it is natural to define polytypic programs as operating over first-class types, such a semantics suffers from a number of drawbacks. This paper describes how to recast that work in a type-erasure semantics, where terms represent type information in a safe manner. The resulting language is simple and easy to implement – we present a prototype implementation of the necessary machinery as a small Haskell library.

2020 ◽  
Author(s):  
Kristóf Umann ◽  
Zoltán Porkoláb

Uninitialized variables have been a source of errors since the beginning of software engineering. Some programming languages (e.g. Java and Python) will automatically zero-initialize such variables, but others, like C and C++, leave their state undefined. While laying aside initialization in C and C++ might be a performance advantage if an initial value can't be supplied, working with such variables is an undefined behavior, and is a common source of instabilities and crashes. To avoid such errors, whenever meaningful initialization is possible, it should be used. Tools for detecting these errors run time have existed for decades, but those require the problematic code to be executed. Since in many cases the number of possible execution paths are combinatoric, static analysis techniques emerged as an alternative. In this paper, we overview the technique for detecting uninitialized C++ variables using the Clang Static Analyzer, and describe various heuristics to guess whether a specific variable was left in an undefined state intentionally. We implemented a prototype tool based on our idea and successfully tested it on large open source projects.


Author(s):  
Vincenzo De Florio

The programming language itself is the focus of this chapter: Fault-tolerance is not embedded in the program (as it is the case e.g. for single-version fault-tolerance), nor around the language (through compilers or translators); on the contrary, faulttolerance is provided through the syntactical structures and the run-time executives of fault-tolerance programming languages. Also in this case a significant part of the complexity of dependability enforcement is moved from each single code to the architecture, in this case the programming language. Many cases exist of fault-tolerance programming languages; this chapter proposes a few of them, considering three cases: Object-oriented languages, functional languages, and hybrid languages. In particular it is discussed the case of Oz, a multi-paradigm programming language that achieves both transparent distribution and translucent failure handling.


Author(s):  
Mark D. Flood ◽  
Matthew McCormick ◽  
Nathan Palmer

We present a variation on literate programming (see Knuth: 1984, 1992) targeting multiple simultaneous readerships, both human (e.g., coders, testers, analysts, etc.) and compilers/interpreters (e.g., C++, Python, Fortran, etc.). The technique exploits existing commenting syntax available in all common programming languages to provide inline documentation and other semantic markup, which can then be used in test generation and code translation. To keep the problem manageable, we restrict attention to scientific function libraries (i.e., libraries of numerical routines adhering to the functional programming rule of “no side effects”). We offer a prototype implementation in XSLT and DocBook.


2021 ◽  
Author(s):  
◽  
Radu Muschevici

<p>Multiple dispatch uses the run time types of more than one argument to a method call to determine which method body to run. While several languages over the last 20 years have provided multiple dispatch, most object-oriented languages still support only single dispatch - forcing programmers to implement multiple dispatch manually when required. This thesis presents an empirical study of the use of multiple dispatch in practice, considering six languages that support multiple dispatch. We hope that this study will help programmers understand the uses and abuses of multiple dispatch; virtual machine implementors optimise multiple dispatch; and language designers to evaluate the choice of providing multiple dispatch in new programming languages.</p>


2021 ◽  
Author(s):  
◽  
Alex Potanin

<p>Modern object-oriented programming languages support many techniques that simplify the work of a programmer. Among them is generic types: the ability to create generic descriptions of algorithms and object structures that will be automatically specialised by supplying the type information when they are used. At the same time, object-oriented technologies still suffer from aliasing: the case of many objects in a program's memory referring to the same object via different references. Ownership types enforce encapsulation in object-oriented programs by ensuring that objects cannot be referred to from the outside of the object(s) that own them. Existing ownership programming languages either do not support generic types or attempt to add them on top of ownership restrictions. The goal of this work is to bring object ownership into mainstream object-oriented programming languages. This thesis presents Generic Ownership which provides perobject ownership on top of a generic imperative language. Surprisingly, the resulting system not only provides ownership guarantees comparable to the established systems, but also requires few additional language mechanisms to achieve them due to full reuse of generic types. In this thesis I formalise the core of Generic Ownership, highlighting that the restriction of this calls, owner preservation over subtyping, and appropriate owner nesting are the only necessary requirements for ownership. I describe two formalisms: (1) a simple formalism, capturing confinement in a functional setting, and (2) a complete formalism, providing a way for Generic Ownership to support both deep and shallow variations of ownership types. I support the formal work by describing how the Ownership Generic Java (OGJ) language is implemented as a minimal extension to Java 5. OGJ is the first publicly available language implementation that supports ownership, confinement, and generic types at the same time. I demonstrate OGJ in practice: show how to use OGJ to write programs and provide insights into the implementations of Generic Ownership.</p>


2007 ◽  
Vol 17 (2) ◽  
pp. 145-205 ◽  
Author(s):  
RONALD GARCIA ◽  
JAAKKO JARVI ◽  
ANDREW LUMSDAINE ◽  
JEREMY SIEK ◽  
JEREMIAH WILLCOCK

AbstractMany modern programming languages support basic generics, sufficient to implement type-safe polymorphic containers. Some languages have moved beyond this basic support, and in doing so have enabled a broader, more powerful form of generic programming. This paper reports on a comprehensive comparison of facilities for generic programming in eight programming languages: C++, Standard ML, Objective Caml, Haskell, Eiffel, Java, C# (with its proposed generics extension), and Cecil. By implementing a substantial example in each of these languages, we illustrate how the basic roles of generic programming can be represented in each language. We also identify eight language properties that support this broader view of generic programming: support for multi-type concepts, multiple constraints on type parameters, convenient associated type access, constraints on associated types, retroactive modeling, type aliases, separate compilation of algorithms and data structures, and implicit argument type deduction for generic algorithms. We find that these features are necessary to avoid awkward designs, poor maintainability, and painfully verbose code. As languages increasingly support generics, it is important that language designers understand the features necessary to enable the effective use of generics and that their absence can cause difficulties for programmers.


2015 ◽  
Vol 15 (4-5) ◽  
pp. 726-741 ◽  
Author(s):  
NATALIIA STULOVA ◽  
JOSÉ F. MORALES ◽  
MANUEL V. HERMENEGILDO

AbstractThe use of annotations, referred to as assertions or contracts, to describe program properties for which run-time tests are to be generated, has become frequent in dynamic programing languages. However, the frameworks proposed to support such run-time testing generally incur high time and/or space overheads over standard program execution. We present an approach for reducing this overhead that is based on the use of memoization to cache intermediate results of check evaluation, avoiding repeated checking of previously verified properties. Compared to approaches that reduce checking frequency, our proposal has the advantage of being exhaustive (i.e., all tests are checked at all points) while still being much more efficient than standard run-time checking. Compared to the limited previous work on memoization, it performs the task without requiring modifications to data structure representation or checking code. While the approach is general and system-independent, we present it for concreteness in the context of the Ciao run-time checking framework, which allows us to provide an operational semantics with checks and caching. We also report on a prototype implementation and provide some experimental results that support that using a relatively small cache leads to significant decreases in run-time checking overhead.


2021 ◽  
Author(s):  
◽  
Constantine Dymnikov

<p>Object ownership allows us to statically control run-time aliasing in order to provide a strong notion of object encapsulation. Unfortunately in order to use ownership, code must first be annotated with extra type information. This imposes a heavy burden on the programmer, and has contributed to the slow adoption of ownership. Ownership inference is the process of reconstructing ownership type information based on the existing ownership patterns in code. This thesis presents OwnKit—an automatic ownership inference tool for Java. OwnKit conducts inference in a modular way: by only considering a single class at the time. The modularity makes our algorithm highly scalable in both time and memory usage.</p>


2021 ◽  
Author(s):  
◽  
Radu Muschevici

<p>Multiple dispatch uses the run time types of more than one argument to a method call to determine which method body to run. While several languages over the last 20 years have provided multiple dispatch, most object-oriented languages still support only single dispatch - forcing programmers to implement multiple dispatch manually when required. This thesis presents an empirical study of the use of multiple dispatch in practice, considering six languages that support multiple dispatch. We hope that this study will help programmers understand the uses and abuses of multiple dispatch; virtual machine implementors optimise multiple dispatch; and language designers to evaluate the choice of providing multiple dispatch in new programming languages.</p>


Sign in / Sign up

Export Citation Format

Share Document