Soft typing

Abstract

During the 80's and early 90's, high-level programming languages supported two different type-checking philosophies: static typing, and dynamic typing. Statically typed programming languages ensured that all programs conformed to a set of typing rules, which implied that programs could not "go wrong". Non-conforming programs were rejected. Dynamically typed programming languages, in contrast, did not reject programs, but rather checked for "type errors" during program execution. ML and Scheme were the prototypical respresentatives of the static and dynamic approachs to typing.Each typing philosophy had distinct advantages and disadvantages. Static typing does not require as much run-time type checking, and the detection of non-conformance supplies programmers with potentially valuable debugging information. The disadvantage of static typing, however, is that are some well-written, meaningful programs that never generate type errors at run time but do not conform to a given system of static typing rules. Semantic typecorrectness is undecidable. As a result, a programmer must rewrite such a program to conform to the type rules.In contrast, dynamic typing permits all programs to be executed, but fails to detect obvious type errors at compile time. Dynamic typing is more flexible at the cost of failing to detect type errors statically.Soft typing seeks to combine the advantages of static typing with the flexibility of dynamic typing. In other words, it provides the expressiveness of a dynamically typed language but it detects and flags potential type errors statically.In our paper, we focused on a core functional language similar to the functional core of both ML and Scheme, presuming that the non-functional features could be handled by extensions to our type system similar to those used in ML. Our key observation was that a type inference engine could be used to insert dynamic run-time checks where needed and inform a programmer that such checks were necessary. The inference engine, however, did not reject programs.At this stage, we noted that the standard ML Hindley-Milner type inference algorithm could be used as a soft type engine for a Scheme-like functional language. After trying the idea on some typical example programs, however, we noted that many typical Scheme programs would need unnecessary run-time checks. The troublesome programs we considered used union types and recursive types. Consequently, we next investigated ways to include true 20 union types (not discriminated union types as in ML) and recursive types in our soft typing system.The second phase of our soft typing research concerned our effort to add union types and recursive types to a Hindley-Milner type inference engine. Recursive types could be added by using circular unification instead of classical unification. Union types, however, have a subtype relation that seems to be inconsistent with the disjoint class assumption of traditional unification methods. Using a classical mathematical technique called slack variables, we could convert subty...

Gradual typing for Smalltalk

“…Gradualtalk is based on Siek and Taha's gradual typing approach. Some other popular partial typing techniques are soft typing [1], pluggable types [3], hybrid typing [4] and like types [38]. Soft typing is a static type system that does not reject potentially erroneous programs, but inserts casts to ensure safety.…”

“…In this context, the possibility to consolidate grown prototypes or scripts with the guarantees of a static type system is appealing. While research in combining static and dynamic typing started more than twenty years ago, recent years have seen a lot of proposals of either static type systems for dynamic languages, or partial type systems that allow a combination of both approaches [1,2,3,4,5,6,7].…”

“…The key to these guarantees is the insertion of runtime casts at the static/dynamic boundaries [8]. 1 Designing and implementing a gradual type system for Smalltalk is a challenging task because of the highly-dynamic nature of the language and the "live" programming environment approach. Indeed, Smalltalk is a reflective language that cannot be, in general, easily typed.…”

Scoped Types and Aspects for Real-Time Java

“…Rather than implement a checker from scratch, we have employed the JAVACOP "pluggable types" checker [1]. Pluggable types [6] are a relatively recent idea, developed as extensions of soft type systems [8] or as a generalization of the ideas behind the Strongtalk type system [7]. The key idea is that pluggable types layer a new static type system over an existing (statically or dynamically typed) language, allowing programmers to have greater guarantees about their programs' behaviour, but without the expense of implementing entirely new type systems or programming languages.…”

Region-Based Memory Management for a Dynamically-Typed Language

“…Since the original region inference is an extension of the ML type inference, however, it was not clear how to apply the region-based memory management to programming languages other than ML, especially dynamically-typed programming languages such as Scheme [13]. In this paper, we show that the region-based memory management can be applied to dynamically-typed languages by combining region inference and soft typing [5].…”