Type Inference for Recursively Constrained Types and its Application to OOP

Eifrig, Jonathan; Smith, Scott F.; Trifonov, Valery

doi:10.1016/s1571-0661(04)80008-2

Cited by 55 publications

(13 citation statements)

References 23 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…For one, constraints may be recursive, allowing typing of self-referential expressions such as λx.xx. Furthermore, constraints allow a representation of conjunctive and disjunctive types [14], without requiring conjunctive and disjunctive type syntax and interpretation. While disjunction can be represented in effect terms via the nondeterministic choice operator (|), a term representation of effect conjunction would require the addition of a parallel-and operation in effects, which is known to significantly increase the complexity of model-checking [10].…”

Section: Constraint Subtyping For λ Tracementioning

confidence: 99%

“…While the logical typing rules are based on previous subtyping constraint systems such as [14] and [33], there is a difference, in that in any judgement Γ, C, H e : τ , the scope of quantified type variablesβ in type schemes in Γ effectively extend to C; in particular, noting the form of the rule ∀-ELIM, we define:…”

Section: Logical Subtyping Judgements and Derivationsmentioning

confidence: 99%

See 1 more Smart Citation

Types and trace effects of higher order programs

2007

Self Cite

View full text Add to dashboard Cite

Abstract. This paper shows how type effect systems can be combined with model-checking techniques to produce powerful, automatically verifiable program logics for higher order programs. The properties verified are based on the ordered sequence of events that occur during program execution, so called event traces. Our type and effect systems infer conservative approximations of the event traces arising at run-time, and model-checking techniques are used to verify logical properties of these histories. Our language model is based on the λ-calculus. Technical results include a type inference algorithm for a polymorphic type effect system, and a method for applying known model-checking techniques to the trace effects inferred by the type inference algorithm, allowing static enforcement of history-and stack-based security mechanisms. A type safety result is proven for both unification and subtyping constraint versions of the type system, ensuring that statically well-typed programs do not contain trace event checks that can fail at run-time.

show abstract

Section: Constraint Subtyping For λ Tracementioning

confidence: 99%

Section: Logical Subtyping Judgements and Derivationsmentioning

confidence: 99%

Types and trace effects of higher order programs

2007

Self Cite

View full text Add to dashboard Cite

show abstract

“…However, we believe this direction is very interesting as well, and we are currently working on it [2]. Previous work on inferring type constraints for object oriented languages includes [11,5,4,10,12].…”

Section: An Alternative Implementation Techniquementioning

confidence: 99%

Just: safe unknown types in Java-like languages.

Lagorio¹,

Zucca²

2007

JOT

View full text Add to dashboard Cite

Most mainstream object-oriented languages, like C++, Java and C#, are statically typed. In recent years, untyped languages, in particular scripting languages for the web, have gained a lot of popularity notwithstanding the fact that the advantages of static typing, such as earlier detection of errors, are widely accepted. We think that one of the main reasons for their widespread adoption is that, in many situations, the ability of ignoring types can be handy to write simpler and more readable code. We propose an extension of Java-like languages which allows developers to forget about typing in strategic places of their programs without losing type-safety. That is, we allow programmers to write simpler code without sacrificing the advantages of static typing. This is achieved by means of inferred type constraints. These constraints describe the implicit requirements on untyped code to be correctly invoked. This flexibility comes at a cost: field accesses and method invocations on objects of unknown types are less efficient than regular field accesses and method invocations. Also, our type system is currently more restrictive than it should be; its extension is the subject of ongoing work. However, the novel approach presented here is quite interesting on its own, as it supports separate compilation and there is zero runtime overhead on code which does not take advantage of the new features. We have implemented our approach on a small, yet significant, Java subset.

show abstract

“…6 Pizza's parametric polymorphism greatly facilitates the implementation of Extensible Visitors. 7 To illustrate this point in more detail, we c o n trast the Pizza implementation with one in Java. In Java, if process is expected to return values, its return type must be declared as Object.…”

Section: Typesmentioning

confidence: 99%

“…If we translate ContainsPt to return Boolean instead of boolean, the Java v ersion of the forUnion method in ContainsPtUnion is: public Object forUnion ( u) f return new Boolean ((((Boolean) (u.lhs.process (this))).booleanValue ()) _ (((Boolean) (u.rhs.process (this))).booleanValue ())) g 6 C++'s 31] template mechanism provides a limited amount of parametric polymorphism. 7 Thorup 33] has proposed a di erent s t yle of type parameterization for Java: virtual types. To implement Extensible Visitor using virtual types, which a r e o verrideable types in classes analogous to virtual methods, and obtain the bene ts of type-checking, we n e e d t o d e c l a r e process as follows (where is the virtual type declared in the processor): For the Pizza version of the same code (see Fig.…”

Section: Typesmentioning

confidence: 99%

Synthesizing object-oriented and functional design to promote re-use

Krishnamurthi

Felleisen

Friedman

1998

ECOOP’98 — Object-Oriented Programming

View full text Add to dashboard Cite

Many problems require recursively speci ed types of data and a collection of tools that operate on those data. Over time, these problems evolve so that the programmer must extend the toolkit or extend the types and adjust the existing tools accordingly. Ideally, this should be done without modifying existing code. Unfortunately, the prevailing program design strategies do not support both forms of extensibility: functional programming accommodates the addition of tools, while object-oriented programming supports either adding new tools or extending the data set, but not both. In this paper, we present a composite design pattern that synthesizes the best of both approaches and in the process resolves the tension between the two design strategies. We a l s o show h o w this protocol suggests a new set of linguistic facilities for languages that support class systems. Evolutionary Software DevelopmentProgramming practice frequently confronts programmers with the following design dilemma. A recursively de ned set of data must be processed by s e v eral di erent tools. In anticipation of future extensions, the data speci cation and the tools should therefore be implemented such that it is easy to 1. add a new variant of data and adjust the existing tools accordingly, a n d 2. extend the collection of tools. Ideally, these extensions should not require any c hanges to existing code. For one, source modi cation is cumbersome and error-prone. Second, the source may not be available for modi cation because the tools are distributed in the form of object code. Finally, i t m a y be necessary to evolve t h e b a s e This dilemma manifests itself in many di erent application areas. A particularly important example arises in the area of programming languages. Language grammars are typically speci ed via BNFs, which denote recursively de ned data sets. Language-processing tools recursively traverse sentences formed from the grammar. In this scenario, a new form of data means an additional clause in the BNF new tools must be able to traverse all possible elements of the (extended) grammar.Unfortunately, p r e v ailing design strategies do not accommodate the required evolution:The \functional" approach, which is often realized with conventional procedural languages, implements tools as procedures on recursive t ypes. While this strategy easily accommodates the extension of the set of tools, it requires signi cant source modi cations when the data set needs to be extended. The (standard) \object-oriented" approach de nes a recursive set of data with a collection of classes, one per variant (BNF clause), and places one method per tool in each c l a s s . I n the parlance of object-oriented design patterns 13], this approach i s k n o wn as the Interpreter pattern. The problem it poses is dual to the problem of the functional approach: variants are easy to add, while tool additions require code modi cations. If the collection of tools is large, the designer may also use the Visitor pattern, a variant o f t h e Interpreter...

show abstract

Type Inference for Recursively Constrained Types and its Application to OOP

Cited by 55 publications

References 23 publications

Types and trace effects of higher order programs

Types and trace effects of higher order programs

Just: safe unknown types in Java-like languages.

Synthesizing object-oriented and functional design to promote re-use

Contact Info

Product

Resources

About