Variant Path Types for Scalable Extensibility Atsushi Igarashi (Kyoto Univ.) joint work with Mirko Viroli (Univ. Bologna)
Background: Scalable Extensibility ● Language support – for extending program components – which can be uniformly applied to components of different scales: ● classes, groups of classes, groups of groups, and so on ● Lot of work on this issue has emerged recently (gbeta, Scala, Concord, CaesarJ, JX, J&)
Extending a Group of Classes ● Inheritance of hierarchies of nested classes – a.k.a higher-order hierarchies [Ernst03] class AST { class Plus ext Exp{ class Exp { } } } Implicit extension class Eval extends AST { class Exp { class Plus ext Exp{ } } }
How “Nested” Inheritance Works [Ernst99][JX] Complete definition of a class is obtained by ● combining bodies of superclasses with possible method overriding ● propagating combination down recursively class Eval { // extends AST // defs inherited from AST // Eval's own defs (with overriding) class Plus ext Exp{ class Exp { // from AST.Plus // from AST.Exp // from Eval.Plus // from Eval.Exp } } }
Two Styles of Semantics ● Nested classes as (dynamic) attributes of objects [gbeta,Scala] var a = new AST(); var p = new a.Plus(); – Run-time type = instance id ( a ) + class ( Plus ) – Naturally lead to a dependent type system ● Nested classes as (static) attributes of classes/groups [JX, Concord, Bruce03WOOD] – Run-time type = fully qualified name of class var p = new AST.Plus();
This Paper ● Addresses typing issues for the second semantics – Without using dependent types ● Less complication ● Less interaction with side effects – With rich subtyping by variant path types ● Formalizes the type system as a core language FJpath ● States a type safety theorem – Hand-written proofs finished
Outline of the Talk ● Preliminary Syntax ● Variant Path Types ● Related Work ● Conclusion
Syntax of FJpath (ver. 0.1) Looks like FJ + (static) nested classes T ::= (to be filled) L ::= class C extends C { ~T ~f ; ~L ~M } M ::= T m ( ~T ~x ){ return e ; } e ::= x | this | e . f | e . m ( ~e ) | new T ( ~e )
Example class AST { class Exp { method print() { ... } } class Const extends Exp { field v; method print() { ... } } class Plus extends Exp { field right, left; method print() { ... } } }
class Eval extends AST { class Exp { method eval() {...} } class Const extends Exp { method eval() { return this.v; } } class Plus extends Exp { method eval() { return right.eval()+left.eval(); } } }
Outline of the Talk ● Preliminary Syntax ● Variant Path Types – Relative and absolute path types – Exact types for safety – Exact and inexact qualifications – Parametric methods ● Related Work ● Conclusion
Requirements for a Type System It should ● be able to express intra-relationship of classes – l“m takes an expression of the same group” ● Preserved by group extension ● achieve type safety (of course!)
Relative Path Types for Intragroup Reference ● This always refers to the current class ● ^This to refer to the enclosing class – ^This. C for a sibling ● ^^This for the further enclosing class, and so on class AST { class Exp { bool eq1( This exp) {...} bool eq2( ^This.Exp exp) {...} } class Plus extends Exp { ^This.Exp left,right; ... } }
Resolution of Relative Path Types ● The signature of a method (or a field type) is computed by substituting – the (static) type of the receiver for This – a prefix of the receiver type for ^ ... ^This ● left of AST.Plus is AST.Exp ● left of Eval.Plus is Eval.Exp ● AST.Exp.eq1() takes AST.Exp eq1(This e); eq2(^This.Exp e); ● AST.Exp.eq2() takes AST.Exp ● AST.Const.eq1() takes AST.Const ● AST.Const.eq2() takes AST.Exp
Exact Types for Safety ● Assuming AST.Plus being a subtype of AST.Exp can break the type system (as usual) AST.Exp e1 = new AST.Plus(); AST.Exp e2 = new AST.Const(); bool b = e1.eq(e2); ● Exact types [Bruce] solve the problem – Exact type @(AST.Plus) (subtype of AST.Plus ) includes only instances of class AST.Plus – Invocation of method taking This (with ^ ) must be on an exact type
Making Subtying Finer-Grained ... ● AST.Exp for all expressions of all ATS s ● @(AST.Exp) for the Exp of the ATS ● Any way to specify e.g., classes of a certain group? AST.Exp @(AST.Plus) @(AST.Exp) class Exp { class Plus ext Exp{ } } class Exp { class Plus ext Exp{ } } @(Eval.Exp)
... By Generalizing @ as Qualification ● It's natural to view @ as qualification! – fully exact type: @AST@Plus – partially exact type: @AST.Exp , AST@Plus ● Inclusion gives rise to subtyping AST.Exp AST@Plus @AST@Exp class Exp { class Plus ext Exp{ } } class Exp { class Plus ext Exp{ } } @Eval.Exp
Restriction on Method Invocations ● All occurrences of ^ ... ^This in argument types have to be replaced with fully exact types @AST@Exp e1; e1.eq1(...); // @AST@Exp -> bool e1.eq2(...); // @AST.Exp -> bool AST.Exp e2; eq1(This e); e2.eq1(...); // not allowed eq2(^This.Exp e); e2.eq2(...); // not allowed – It doesn't necessarily mean the receiver type must be (fully) exact! @AST.Exp e3; e3.eq1(...); // not allowed e3.eq2(...); // @AST.Exp -> bool
Revised Syntax A ::= C | A @ C absolute path types E ::= ^ ... ^This | @ C | E @ C exact types T ::= ^ ... ^This | C | @ C | T . C | T @ C types L ::= class C extends C { ~T ~f ; ~L ~M } M ::= T m ( ~T ~x ){ return e ; } e ::= x | this | e . f | e . m ( ~e ) | new A ( ~e )
Outline of the Talk ● Preliminary Syntax ● Variant Path Types – Relative and absolute path types – Exact types for safety – Exact and inexact qualifications – Parametric methods ● Related Work ● Conclusion
Exact Type Parameters for “Group-Polymorphic” Methods Consider a method to replace both operands of Plus with a given expression ● Such a group-polymorphic method can be described by a parametric method as in Java 5.0 [Igarashi-Saito-Viroli05] <exact X extends AST> void repl_left(X@Plus p, X.Exp e){ p.left = e; p.right = e; } – X must range only over exact types – Otherwise, the caller could pass nodes from different kinds of expressions
Revised^2, Final Syntax A ::= @ C | A @ C absolute path types E ::= ^ ... ^This | ^ ... ^ X | @ C | E @ C exact types T ::= ^ ... ^This | ^ ... ^ X | @ C | C | T . C | T @ C types L ::= class C extends C { ~T ~f ; ~L ~M } M ::= < ~ X extends ~ T > T m ( ~T ~x ){ return e ; } e ::= x | this | e . f | e . m < ~T >( ~e ) | new A ( ~e )
Variant Path Types: Summary ● Relative Path Types – for describing intragroup relationship ● Exact/inexact qualifications – for fine-grained control over exactness and subtyping ● Parametric methods w/ exact type variables ● FJpath = FJ + nested inheritance + variant path types + parametric methods – Formalization and Type Soundness Theorem (See the paper!)
Outline of the Talk ● Informal Semantics of Inheritance ● Variant Path Types – Relative and absolute path types – Exact types for safety – Exact and inexact qualifications – Parametric methods ● Related Work ● Conclusion
Related Work ● gbeta, Caesar/J ● Scala ● Nested Inheritance/Intersection (JX) [Nystrom et al.] ● Concord [Jolly-Drossopoulou-Anderson-Ostermann] ● Lightweight family polymorphism [Igarashi-Saito- Viroli05] ● Bruce's series of work on binary methods, matching, statically type safe virtual types, and LOOJ ● Variant parametric types (Java wildcards)
Comparison with Variant Parametric Types (Java wildcards) Variant parametric types Variant path types ● Invariant types C<T> ● Invariant qualification “ @ ” – C<S> <: C<T> if S = T – T@C <: T@D if C = D ● Covariant types C<+T> ● Covariant qualification “ . ” ( C<? extends T> ) – T.C <: T.D if C extends D – C<+S> <: C<+T> if S <: T – T@C <: T.C – C<T> <: C<+T> – restricted method access – restricted method access Basic.Exp List<+Num> Basic@Plus MyList<+Num> List<Int> List<Dbl> Eval.Exp Basic@Var MyList<Int> @Eval@Var
Types in JX [Nystrom et al.] ● Dependent classes: x.class , x.f.class ● Prefix types: C[T] – The innermost enclosing class of T that is a subclass of C – AST[this.class].Exp ≈ ^This.Exp ● Inheritance is subtyping void repl_left(AST.Plus p, AST[p.class].Exp e){ p.left = e; }
Conclusion Variant path types as an alternative to dependent types in the context of nested inheritance ● Clear separation of types and values possible ● Fine-grained control over subtyping by two kinds of qualification Ongoing/future work: ● Mechanism to locally “exactize” .C types? ● Type inference for parametric methods – Preliminary results in a simpler setting [Igarashi- Saito-Viroli05] ● Metatheory for typechecking
Recommend
More recommend
