scholarly journals Applying Optimizations for Dynamically-typed Languages to Java

Author(s):  
Matthias Grimmer ◽  
Stefan Marr ◽  
Mario Kahlhofer ◽  
Christian Wimmer ◽  
Thomas Würthinger ◽  
...  
Keyword(s):  
2021 ◽  
Vol 54 (5) ◽  
pp. 1-38
Author(s):  
Jana Dunfield ◽  
Neel Krishnaswami

Bidirectional typing combines two modes of typing: type checking, which checks that a program satisfies a known type, and type synthesis, which determines a type from the program. Using checking enables bidirectional typing to support features for which inference is undecidable; using synthesis enables bidirectional typing to avoid the large annotation burden of explicitly typed languages. In addition, bidirectional typing improves error locality. We highlight the design principles that underlie bidirectional type systems, survey the development of bidirectional typing from the prehistoric period before Pierce and Turner’s local type inference to the present day, and provide guidance for future investigations.


1990 ◽  
Vol 19 (342) ◽  
Author(s):  
Jens Palsberg ◽  
Michael I. Schwartzbach

<p>Subclassing is reuse of class definitions. It is usually tied to the use of class names, thus relying on the order in which the particular classes in a program are created. This is a burden, however, both when programming and in theoretical studies.</p><p> </p><p>This paper presents a structural notion of subclassing for typed languages. It is a direct abstraction of the SMALLTALK interpreter and the separate compilation technique of MODULA. We argue that it is the most general mechanism which can be supported by the implementation while relying on the type-correctness of superclasses. In short, it captures type-safe code reuse.</p>


2006 ◽  
Vol 16 (4-5) ◽  
pp. 375-414 ◽  
Author(s):  
MATTHIAS BLUME ◽  
DAVID McALLESTER

Even in statically typed languages it is useful to have certain invariants checked dynamically. Findler and Felleisen gave an algorithm for dynamically checking expressive higher-order types called contracts. They did not, however, give a semantics of contracts. The lack of a semantics makes it impossible to define and prove soundness and completeness of the checking algorithm. (Given a semantics, a sound checker never reports violations that do not exist under that semantics; a complete checker is – in principle – able to find violations when violations exist.) Ideally, a semantics should capture what programmers intuitively feel is the meaning of a contract or otherwise clearly point out where intuition does not match reality. In this paper we give an interpretation of contracts for which we prove the Findler-Felleisen algorithm sound and (under reasonable assumptions) complete. While our semantics mostly matches intuition, it also exposes a problem with predicate contracts where an arguably more intuitive interpretation than ours would render the checking algorithm unsound. In our semantics we have to make use of a notion of safety (which we define in the paper) to avoid unsoundness. We are able to eliminate the “leakage” of safety into the semantics by changing the language, replacing the original version of unrestricted predicate contracts with a restricted form. The corresponding loss in expressive power can be recovered by making safety explicit as a contract. This can be done either in ad-hoc fashion or by including general recursive contracts. The addition of recursive contracts has far-reaching implications, deeply affecting the formulation of our model and requiring different techniques for proving soundness.


Sign in / Sign up

Export Citation Format

Share Document