1 a comparative study of language support for generic programming oopsla 2003 roland garcia jaakko...

36
1 A Comparative Study Of Language Support for Generic Programming Oopsla 2003 Roland Garcia Jaakko Jarvi Andrew Lumsdaine Jeremy Siek Jeremiah Wilcock Presented by: Regine Issan

Upload: cecil-francis

Post on 04-Jan-2016

215 views

Category:

Documents


2 download

TRANSCRIPT

Page 1: 1 A Comparative Study Of Language Support for Generic Programming Oopsla 2003 Roland Garcia Jaakko Jarvi Andrew Lumsdaine Jeremy Siek Jeremiah Wilcock

1

A Comparative Study Of Language Support for Generic

ProgrammingOopsla 2003

• Roland Garcia • Jaakko Jarvi• Andrew Lumsdaine• Jeremy Siek • Jeremiah Wilcock

Presented by: Regine Issan

Page 2: 1 A Comparative Study Of Language Support for Generic Programming Oopsla 2003 Roland Garcia Jaakko Jarvi Andrew Lumsdaine Jeremy Siek Jeremiah Wilcock

2

Generics…• What’s the point ?

– reusable algorithms , reusable data structures • Expressed using type parameter• No programming language does this right !

• Previous attempts– C++ STL ?!– Java type safe containers ?!– LEDA ?!

• This work:– Generic graph library in 6 PL

http://www.osl.iu.edu/research/comparing

Page 3: 1 A Comparative Study Of Language Support for Generic Programming Oopsla 2003 Roland Garcia Jaakko Jarvi Andrew Lumsdaine Jeremy Siek Jeremiah Wilcock

3

Research Results • 8 criterions indicating generics support

C++ Java C# Eiffel ML

multiple constraints

implicit instantiation

retro active modeling

Associated types access

Multi type concepts

separate compilation

Constraints between associated types

extended research …

Page 4: 1 A Comparative Study Of Language Support for Generic Programming Oopsla 2003 Roland Garcia Jaakko Jarvi Andrew Lumsdaine Jeremy Siek Jeremiah Wilcock

4

Our Graph Library

all we want is:BFS (G g,Vertex s, ColorMap c,Visitor vis)

Page 5: 1 A Comparative Study Of Language Support for Generic Programming Oopsla 2003 Roland Garcia Jaakko Jarvi Andrew Lumsdaine Jeremy Siek Jeremiah Wilcock

5

Terminology To features understanding associated typessimple example• Iterator

element Iter.next()

element is associated type• What about BFS ReadWriteMap ?

Page 6: 1 A Comparative Study Of Language Support for Generic Programming Oopsla 2003 Roland Garcia Jaakko Jarvi Andrew Lumsdaine Jeremy Siek Jeremiah Wilcock

6

Terminology to feature understanding:associated types

graph library example• type parametes: G, C, vis• what are G associated types ?

– G models VertexListGraph and IncidenceGraph interfaces• IncidenceGraph { “interface”}

– G::out_edge_iter out_edges (const G&, vertex )

– vertex src (edge, const G& )• VertexListGraph {“interface”}

– G::vertex_iter vertices (const G&)

4 associated types

Page 7: 1 A Comparative Study Of Language Support for Generic Programming Oopsla 2003 Roland Garcia Jaakko Jarvi Andrew Lumsdaine Jeremy Siek Jeremiah Wilcock

7

Terminology to features understanding: associated types restriction

BFS (G g, Vertex s, ColorMap c,Visitor vis)Any restrictions ?

C.key type == G.Vertex type G::vertex type == Vertex type

C A.T: { key , value}G A.T : {Vertex, edge, out_edge_iter, vertex_iter }

– Constraint associated types feature C.key type == G.Vertex type

– access associated types featurecall: BFS (G g, G::vertex s, ColorMap c,Visitor vis)

extended research…

Page 8: 1 A Comparative Study Of Language Support for Generic Programming Oopsla 2003 Roland Garcia Jaakko Jarvi Andrew Lumsdaine Jeremy Siek Jeremiah Wilcock

8

Terminology to features understanding:concept, model

algorithm restrict type parameters using Concepts • C is a ColorMap

Concept set of requirements on a type or on a set of types • method signatures

– colorMap: value_t get (key_t)• support associated types access

– C.key_t• A.T relationship

– (C.key type == G.Vertex type)» Almost as Interface

A type models a concept by meeting its requirements. • Explicit model: class C implements I• Implicit model: structural conformance

multiple constraints on type parameter– G models vertexListGraph and IncidenceGrpah

conceptsmulti type concept

– concept set restrictions on several types

Page 9: 1 A Comparative Study Of Language Support for Generic Programming Oopsla 2003 Roland Garcia Jaakko Jarvi Andrew Lumsdaine Jeremy Siek Jeremiah Wilcock

9

• Concept A is said to refine concepts c1,c2, … if its requirements includes concepts c1,c2, …. Requirements• Usage:

– G models vertexListGraph and IncidenceGrpah concepts– What if P.L doesn’t support multiple constraints on G ?

• Create a single concept from scratch• Or … refine!

– ML: include Java: extends– EiffelL inherit C#: (:)

Terminology: concept refinement

Page 10: 1 A Comparative Study Of Language Support for Generic Programming Oopsla 2003 Roland Garcia Jaakko Jarvi Andrew Lumsdaine Jeremy Siek Jeremiah Wilcock

10

Introduction to generics in ML

ML Structure ~ OOP Class ~ typeML Signature ~ OOP Interface ~ Concept

Structure f1Model = structtype f1_field = int fun calc (x: int ) = x*x end

EndSignature f1Concept = Sig

type f1_fieldval calc: f1_feild -> f1_feild

End

Signature S = sigstructure f1: f1Concept

EndFunctor makeInstance (Params: S ) = struct

fun go x = Params.f1.calc (Params.f1.calc ( x) )EndStructure F= makeInstance ( struct structure f1= f1Model end )F.go 5

Structure meet signature Signature restrict typeRepresents ML concept

algorithm expressed with abstract type

Instantiate algorithm with concrete type (f1Model)

S is abstract type

Page 11: 1 A Comparative Study Of Language Support for Generic Programming Oopsla 2003 Roland Garcia Jaakko Jarvi Andrew Lumsdaine Jeremy Siek Jeremiah Wilcock

11

Apple Example: C++

//bool better (const T&, const T&)

Template <class Comparable>

const Comparable& go (const Comparable& x, const Comparable& y) {

if ( better (x,y)) return x; return y;

}

Struct Apple {

int rating;

Apple (int r) : rating (r) {}

};

Bool better (const Apple& a, const Apple& b)

{ return b. rating < a. rating; }

Int main (char*[]){

Apple a1(3),a2(5);

Apple& a3 = go (a1,a2)

Comparable Concept documented

Generic algorithm as function template with type

parameter

no constraint on type parameter

Apple implicitly models Comparable

Implicit instantiation

Page 12: 1 A Comparative Study Of Language Support for Generic Programming Oopsla 2003 Roland Garcia Jaakko Jarvi Andrew Lumsdaine Jeremy Siek Jeremiah Wilcock

12

Apple Example: Java

Interface Comparable <T> { boolean better (T x); }

Class pick { static <T extends Comparable<T>> T go (T a, T b) { if ( a. better (b)) return a; return b; }

Class Apple implements Comparable<Apple> { Apple (int r) { rating = r; } public boolean better (Apple x) {return x .rating < rating; } Int rating;}

Public class Main() {public static void main (String[] args) {

Apple a1 = new Apple (3); Apple a2 = new Apple (5); Apple a3 = pick. go (a1,s2) }}

Comparable concept as

interface with type parameter

constraintextend a class and implement a set

of interfacesMultiple constraints on type parameter

Apple explicitly models

Comparable

Generic algorithm in class method with type

parameter

Implicit instantiation

Page 13: 1 A Comparative Study Of Language Support for Generic Programming Oopsla 2003 Roland Garcia Jaakko Jarvi Andrew Lumsdaine Jeremy Siek Jeremiah Wilcock

13

Apple example: C#

Interface Comparable <T> { bool better (T x); }

Class Pick{

Static T go <T> (T a, T b) where T: Comparable<T> {if (a. better (b)) return a; return b;}

}

Class Apple : Comparable<Apple> { public Apple (int r) {rating = r;}

public bool better (Apple x) { return x .rating < rating; }private int rating;

}

Public class Main_eg {public static int Main (string[] args) {

Apple a1 = new Apple(3); a2 = new Apple(5);

Apple a3 = pick.go <Apple> (a1,a2);

return 0;

}

Comparable concept as Java

constraintNo more than one constraint on type parameter (Gyro,

not .NET)

Apple explicitly models

Comparable as in Java

Generic algorithm as Java

Explicit instantiationProgrammer specifies type

parameters (and associated type parameter)

Page 14: 1 A Comparative Study Of Language Support for Generic Programming Oopsla 2003 Roland Garcia Jaakko Jarvi Andrew Lumsdaine Jeremy Siek Jeremiah Wilcock

14

Apple Example: EiffelDeferred class Comparable [T] Feature better (a : T) :BOOLEAN is deferred

end

Class Pick [T -> Comparable [T] ] Feature go (a: T, b: T) is do if a. better (b) Result:=a else Result:= b; endEnd

EndClass Apple inherit Comparable [Apple] end

Create make

Feature make (r: INTEGER) is do rating:= r end

better (a :Apple) : BOOLEAN is do Result:= rating < a. rating; endEndfeature {Apple} rating: INTEGER

endClass ROOT_CLASS

create main Feature main is

local a1, a2, a3 :Apple;

picker :Pick [Apple] do create picker; create a1.make (3); create a2.make(5);

a3 := picker. Go (a1,a2)End

end

Comparable concept as deferred class with type

parameter

constraintNo more than one constraint on

type parameter

Apple explicitly models

Comparable

Explicit instantiation

Page 15: 1 A Comparative Study Of Language Support for Generic Programming Oopsla 2003 Roland Garcia Jaakko Jarvi Andrew Lumsdaine Jeremy Siek Jeremiah Wilcock

15

Evaluation: retroactive modeling feature support

• If you build new generic algorithm – T is constrained by completely new concept

• Can T be substituted by existing types ?– Can existing types model the new concept ?

• ML: yesIf you add: Signature newS = sig … end

structures implicitly model newS• Java, C#, Eiffel:

– If you add : Interface newI = { … }no class models it until it’s explicitly declared

C++ Java C# Eiffel ML

Retroactive modeling

{}

No concept

{-} {-} {-} {+}

Page 16: 1 A Comparative Study Of Language Support for Generic Programming Oopsla 2003 Roland Garcia Jaakko Jarvi Andrew Lumsdaine Jeremy Siek Jeremiah Wilcock

16

Evaluation: implicit instantiation feature support

No Type parameters in generic instantiation– avoid verbose code

C++ Java C# Eiffel ML

Retro active modeling { } {-} {-} {-} {+}

implicit instantiation {+} {+} {-, Gyro} {-} {-}

C++: go (a1,a2)Java: pick. go (a1,s2)C#: pick. go <Apple> (a1,a2);Eiffel: picker :Pick [Apple]

a3 := picker. Go (a1,a2)

ML: Structure F= calcF10F2

( struct structure f1= f1Model structure f2= f2Model end )

F.go 5

Page 17: 1 A Comparative Study Of Language Support for Generic Programming Oopsla 2003 Roland Garcia Jaakko Jarvi Andrew Lumsdaine Jeremy Siek Jeremiah Wilcock

17

Evaluation: Separate compilation feature support

• Can generic algorithm be type checked and compiled independently from its call site ?

– Benefits– catch type errors as early as possible – fast compilation and small executable

type arguments constraints => separate compilation support

C++ Java C# Eiffel ML

Retro active modeling {} {-} {-} {-} {+}

implicit instantiation {+} {+} {-,Gyro} {-} {-}

separate compilation {-} {+} {+} {+} {+}

Page 18: 1 A Comparative Study Of Language Support for Generic Programming Oopsla 2003 Roland Garcia Jaakko Jarvi Andrew Lumsdaine Jeremy Siek Jeremiah Wilcock

18

Evaluation:

Separate compilation feature support in C++

• No constraints on type parameter• Pitfalls

– executable size– Type checking against template body , not parameters– Invocation with improper type

• non informative error messages• expose template internals

Template <class Comparable> const Comparable& Template <class Comparable> const Comparable& go (const Comparable& x, const Comparable& y) {if ( better (x,y)) …}go (const Comparable& x, const Comparable& y) {if ( better (x,y)) …}

… … go (a1,a2) …go (a1,a2) …

Page 19: 1 A Comparative Study Of Language Support for Generic Programming Oopsla 2003 Roland Garcia Jaakko Jarvi Andrew Lumsdaine Jeremy Siek Jeremiah Wilcock

19

Multiple constraints feature: what do we want ?

BFS: G models VertexListGraph & IncidenceGraph

multiple constraints on G ?!

what if PL don’t’ support ?

Page 20: 1 A Comparative Study Of Language Support for Generic Programming Oopsla 2003 Roland Garcia Jaakko Jarvi Andrew Lumsdaine Jeremy Siek Jeremiah Wilcock

20

Evaluation: Multiple constraints feature support

Can you set more than one constraint on a type parameter ?

C++ Java C# Eiffel ML

Retro active modeling {} {-} {-} {-} +

implicit instantiation {+} {+} {-,Gyro} {-} {-}

Separate compilation {-} {+} {+} {+} {-}

multiple constraints {} {+} {-, Gyro} {-} {~}

• C++: no constraints on type parameters …• Java: extend a class, implement a set of interfaces• Eiffel: not supported, build new concept (ie, deferred class)

ML: not as we would want. lets see …

Page 21: 1 A Comparative Study Of Language Support for Generic Programming Oopsla 2003 Roland Garcia Jaakko Jarvi Andrew Lumsdaine Jeremy Siek Jeremiah Wilcock

21

Signature GraphSig = Sig

Type graph_t Eqtype vertex_t

End

Signature IncidenceGraphSig =Sig Include GraphSig …end

Signature VertexListGraphSig =Sig Include GraphSig…end

Signature vertexListAndIncidenceGraph =

Sig

Include IncidenceGraphSig

Include VertexListGraphSig

End

Evaluation: Multiple constraints in ML simple solution : Refinement

What is wrong ?!

Signatures Include expressed

Concept refinement

Page 22: 1 A Comparative Study Of Language Support for Generic Programming Oopsla 2003 Roland Garcia Jaakko Jarvi Andrew Lumsdaine Jeremy Siek Jeremiah Wilcock

22

• idea:– G is constrained multiple times ? Let it appear multiple times !

• Each time it will be constrained by different concept !Signature GraphSig = Sig

Type graph_t Eqtype vertex_t EndSignature IncidenceGraphSig = Sig

Include GraphSig Type edge_tVal out_edges: graph_t -> vertex_t -> edge_t list

end Signature VertexListGraphSig = Sig

Include GraphSigVal vertices: graph_t -> vertex_t list

End

Signature BFSSig =SigStructure G1: InceidenceGraphSigStructure G2: VertexListGraphSigStructure C: ColorMapSigStructure Vis: BFSVisitor SigSharing G1 = G2 ….

End

Evaluation: Multiple constraints in ML workaround when refinement fails – duplicate the structure

Sharing common nested elements refer the same

entity

Page 23: 1 A Comparative Study Of Language Support for Generic Programming Oopsla 2003 Roland Garcia Jaakko Jarvi Andrew Lumsdaine Jeremy Siek Jeremiah Wilcock

23

Signature BFSSig =SigStructure G1: InceidenceGraphSigStructure G2: VertexListGraphSigStructure C: ColorMapSigStructure Vis: BFSVisitor SigSharing G1 = G2 ….

Endfunctor MakeBFS (Params: BFSPSg) =struct

fun breadth_first_search graph root visitor map = … endEndStructure ALGraph =Struct

Datatype graph_t = Data of int * int list Array.arrayType vertex_t = int type edge_t = int*intFun out_edges Data(n,g) vertex = ….Fun vertices Data(n,g) = ….

End;

Structure BFS = MakeBFS ( struct Structure G1 = ALGraph Structure G2 = ALGraph Structure C = ALGColorMap Structure Vis = VisitImpl End)

BFS.breadth_first_search …

Evaluation: multiple constraints in ML- workaround when refinement fails result in awkward code

models both restrictions !

Page 24: 1 A Comparative Study Of Language Support for Generic Programming Oopsla 2003 Roland Garcia Jaakko Jarvi Andrew Lumsdaine Jeremy Siek Jeremiah Wilcock

24

Look at BFS generic algorithm :

template <class G, Class C, Class Vis>

void breadth_first_search (const G& graph,

????? sourceNode, C colorMap, Vis visitor);

Is it possible to express that ????? Is graph node type ?

traits + typedefs

just another class template

provide Compile time A.T access

Evaluation: associated type access in C++

Page 25: 1 A Comparative Study Of Language Support for Generic Programming Oopsla 2003 Roland Garcia Jaakko Jarvi Andrew Lumsdaine Jeremy Siek Jeremiah Wilcock

25

Class AdjacencyList { //models IncidenceGraph and vertexListGraph Public: Typedef int vertex; … }

Template <typename G>Struct graph_traits { typedef G::vertex vertex; … }}

template <class G, Class C, Class Vis>void breadth_first_search (const G& graph,

typename graph_traits<G> :: vertex sourceNode, C colorMap, Vis visitor);

AdjacencyList g; … Breadth_first_search (g,0, ….)

Evaluation: associated type access in C++ using traits

GT must have vertex typedef

G vertex A.T accessed graph_trait

Typename : unknown identifier is considered as type

Page 26: 1 A Comparative Study Of Language Support for Generic Programming Oopsla 2003 Roland Garcia Jaakko Jarvi Andrew Lumsdaine Jeremy Siek Jeremiah Wilcock

26

So easy: associated types encapsulated within the type

signature ColorMapSig = sig type key_t type val_t Val get key_t ->value_t … endSignature BFSSig = Sig

Structure Vis: BFSVisitorSig Sturcure G: VertexListGraphAndIncidenceGraph Structure C: ColorMapSig

access C.key_t C.val_t when neededEnd– constraint on associated types:

sharing type C.key_t = C.val_t !

Evaluation: associated type access in ML

Page 27: 1 A Comparative Study Of Language Support for Generic Programming Oopsla 2003 Roland Garcia Jaakko Jarvi Andrew Lumsdaine Jeremy Siek Jeremiah Wilcock

27

• Ideally , associated are encapsulated within the type• ML:

– Structures naturally encapsulate types

• C :– Force encapsulation using typedefs

• Java,C#,Eiffel – Classes/interfaces cant encapsulate types

• only methods and member variables

“Solution”: add associated types to the type parameter list !!!

lets see …

Evaluation: associated type accesswhat about Java, C#, Eiffel ?

Page 28: 1 A Comparative Study Of Language Support for Generic Programming Oopsla 2003 Roland Garcia Jaakko Jarvi Andrew Lumsdaine Jeremy Siek Jeremiah Wilcock

28

public interface GraphEdge <Vertex> {

Vertex source(); Vertex target();

}

Public interface VertexListGraph

<Vertex, VertexIterator extendIterator<Vertex>> {

VertexIterator vertices();…

}

public interface IncidenceGraph

<Vertex, Edge, OutEdgeIterator extends Iterator<Edge>>{

OutEdgeIterator out_edges(Vertex v);…

}

Evaluation: associated type access in Java adding A.T to interface declaration

Vertex associated type in interface parameter list

Edge associated type in interface parameter list

Page 29: 1 A Comparative Study Of Language Support for Generic Programming Oopsla 2003 Roland Garcia Jaakko Jarvi Andrew Lumsdaine Jeremy Siek Jeremiah Wilcock

29

Public class breadth_first_search { Public static <

Vertex, Visitor extends BFSVisitor, ColorMap extends ReadWriteMap <Vertex, Integer>

Edge extends GraphEdge<Vertex>, VertexIterator extends Iterator <Vertex>, OutEdgeIterator extends IIterator<Edge>,

G extends VertexListGraph < Vertex, VertexIterator> ,

IncidenceGraph <Vertex, Edge, OutEdgeIterator> > void go ( G g, Vertex s, ColorMap c, Visitor vis); }

Evaluation: associated type access in Java

referring interfaces AT in generic method

4 method parameters.3 associated types

specified in interface type list

Capture A.T relationships colorMap key is same type as graph

vertexS tart vertex is same type as graph

vertex

Page 30: 1 A Comparative Study Of Language Support for Generic Programming Oopsla 2003 Roland Garcia Jaakko Jarvi Andrew Lumsdaine Jeremy Siek Jeremiah Wilcock

30

Public interface VertexListGraph<Vertex, VertexIterator extendIterator<Vertex>> { VertexIterator vertices();}

public interface IncidenceGraph<Vertex, Edge, OutEdgeIterator extends Iterator<Edge>>{

OutEdgeIterator out_edges(Vertex v);}public class adjacency_list

implements VertexListGraph < Integer, Iterator<Integer> >, IncidenceGraph < Integer, simpleEdge<integer>, Iterator<simpleEdge<integer> > > { …}

breadth_first_search.go (g, src,color_map,visitor)

Evaluation: associated type access in Javareferring interfaces AT in implementing classes

Page 31: 1 A Comparative Study Of Language Support for Generic Programming Oopsla 2003 Roland Garcia Jaakko Jarvi Andrew Lumsdaine Jeremy Siek Jeremiah Wilcock

31

A.T as part of type parameters list ?!• We can access then

• within generic algorithm• we must access them every time we refer a concept

– Even if algorithm does not use it – lengthy code – Constraints repetition– Breaking encapsulation

Expose potentially helper types

Evaluation: associated type access in Java,C#,Eiffelsummery

encapsulate associated types !!!

Page 32: 1 A Comparative Study Of Language Support for Generic Programming Oopsla 2003 Roland Garcia Jaakko Jarvi Andrew Lumsdaine Jeremy Siek Jeremiah Wilcock

32

Evaluation: associated type access

• Motivation: express relation betwee A.T

C++ Java C# Eiffel ML

associated types access

{+} {~} {~} {~} {+}

ML: encapsulate within structure, sharingC++: encapsulated within class,

traits used to access them captures associated types relations

Java,c#,eiffe: A.T explicitly specified in type parameter list of a concept

Page 33: 1 A Comparative Study Of Language Support for Generic Programming Oopsla 2003 Roland Garcia Jaakko Jarvi Andrew Lumsdaine Jeremy Siek Jeremiah Wilcock

33

Evaluation: multi type concept• Can one concept constrain several types ?• ML

– Signature • Encapsulate structures and methods

• OOP: – Interface

• constrains a single class

OOP concepts are not as strong as concepts ! , why ? Lets see …

C++ Java C# Eiffel ML

Multi type concepts

{-} {-} {-} {-} {+}

Page 34: 1 A Comparative Study Of Language Support for Generic Programming Oopsla 2003 Roland Garcia Jaakko Jarvi Andrew Lumsdaine Jeremy Siek Jeremiah Wilcock

34

• Algorithm ConceptA: { Vector<V> mult Scalar<S> => Vector<V>

Scalar<S> mult Vector<V> => Vector<V>}

• Oop interpretation– Vector<V> has:

• Vector<V> mult (Scalar<S>)

• Scalar<S> has:• Vector<V> mult (Vector<V>)

two interfaces required to express ConceptA ! interfaces cant express multi types concept !

– Restrict implementing class only, not multiple classes

What if conceptA is refined ? (2^n interfaces)

Evaluation: multi type concept multi type concept split into several interfaces

Page 35: 1 A Comparative Study Of Language Support for Generic Programming Oopsla 2003 Roland Garcia Jaakko Jarvi Andrew Lumsdaine Jeremy Siek Jeremiah Wilcock

35

Research Results • criterions to indicate PL generics support

C++ Java C# Eiffel ML

multiple constraints {} {+} {-,Gyro} {-} {~}

implicit instantiation {+} {+} {-} {-} {-}

separate compilation {-} {+} {+} {+} {+}

retro active modeling {} {-} {-} {-} {+}

Associated types access

{+} {~} {~} {~} {+}

Multi type concepts {} {-} {-} {-} {+}

Page 36: 1 A Comparative Study Of Language Support for Generic Programming Oopsla 2003 Roland Garcia Jaakko Jarvi Andrew Lumsdaine Jeremy Siek Jeremiah Wilcock

36

Questions !?