Languages of the future: ?mega the 701st programming language

1
Languages of the future?mega the 701st
programming language

• Tim Sheard
• Portland State University
• (formerly from OGI/OHSU)

2
Whats wrong with todays languages?

• The semantic gap
• What does the programmer know about the program?
  How is this expressed?
• The temporal gap
• Systems are configured with new knowledge at
  many different times compile-time, link-time,
  run-time. How is this expressed?

3
What will languages of the future be like?

• Support reasoning about a program from within the
  programming language.
• Within the reach of most programmers No Ph.D.
  required.
• Support all of todays capabilities but organize
  them in different ways.
• Separate powerful but risky features from the
  rest of the program, spell out obligations needed
  to control the risk, ensure that obligations are
  met.
• Provide a flexible hierarchy of temporal stages.
  Track important attributes across stages.

4
How do we get there?

• In small steps, Im afraid . . .
• Two small contributions
• Putting the Curry-Howard isomorphism to work for
  regular programmers
• Exploiting staged computation
• In this talk, Ill only talk about the first one

5
Step 1- Putting Curry-Howard to work

• Programming by manipulating proofs of important
  semantic properties
• What is a proof?
• How do we exploit proofs?
• ? is a new point in the design space somewhere
  between a
• Programming language
• A logic

6
We need something in between to two extremes!
Haskell Python OCaml Pascal
Java C C
7
Dimensions

• Formal methods systems
• Have too few formal systems users. We cant solve
  the worlds problems with a handful of users. And,
  for the most part, the users are thinkers not
  hackers
• The systems themselves are used to reason about
  systems, but arent designed to execute programs.
  For the most part, they dont have rich
  libraries, I/O etc.
• Have a steep learning curve. It takes a Ph.D. to
  learn to effectively use these tools.

8
Steps between the concrete and the clouds

• Train more users to use formal systems, or add
  formal features to lower level languages so
  existing programmers can use formal methods.
• Design practical extensions for formal systems
  and build robust compilers for them, or add
  formal extensions to practical languages.

9
Haskell
Python OCaml Pascal Java
C C
10
Curry Howard

• Types are properties
• Programs are proofs
• A program with type T witness that there exists a
  program with type T.
• If all we have is simple types like Int or
  (Bool,String) or Tree Bool, then the properties
  are too simple to think of them as very useful
  proofs.

11
What is a proof?
Am I odd or even?
3

• Requirements for a legal proof
• Even is always stacked above odd
• Odd is always stacked below even
• The numeral decreases by one in each stack
• Every stack ends with 0

12
1 1 0
2 1 1
3 1 2
13
Algebraic Datatypes

• Inductively formed structured data
• Generalizes enumerations, records tagged
  variants
• data Color Red Blue Green
• data Address A Number Street Town Province
  MailCode
• data Person Teacher Class Student Major
• Types are used to prevent the construction of
  ill-formed data.
• Pattern matching allows abstract high level (yet
  still efficient) access

14
ADTs provide an abstract interface to heap data.
We can define parametric polymorphic data

• Data Tree a
• Fork (Tree a) (Tree a)
• Node a
• Tip
• Fork Tree a -gt Tree a -gt Tree a
• Node a -gt Tree a
• Tip Tree a

Inductivley defined data allows structures of
unbounded size
Functions defined with pattern matching
Sum Tree Int -gt Int Sum Tip 0 Sum (Node x)
x Sum (Fork m n) sum m sum n
Note the data declaration introduces values and
functions that construct instances of the new
type.
15
Fork (Fork (Node 5) Tip) Tip
Fork
Fork
Tip
Node
Tip
5
16
ADT Type Restrictions

• Data Tree a
• Fork (Tree a) (Tree a)
• Node a
• Tip
• Fork Tree a -gt Tree a -gt Tree a
• Node a -gt Tree a
• Tip Tree a

Restriction the range of every constructor
matches exactly the type being defined
17
Integer Indexed Type-Constructors

• Z Even 0
• E Odd m -gt Even (m1)
• O Even m -gt Odd (m1)
• O(E (O Z))
• Odd (1110)

Note Even and Odd are type constructors indexed
by integers
18
Generalized Algebraic Data Structures

• Like ADT
• Remove the range-type restriction
• Allow type constructors to be indexed by things
  other than normal types.

19
The kind decl introduces new types

• Allow algebraic definitions to define new kinds
  as well as new data types
• Example of new type
• data List a Nil Cons a (List a)
• Nil and Cons are new values.
• They are classified by type List
• Nil a
• Cons a -gt List a -gt List a
• Example of new kind
• kind Nat Zero Succ Nat
• Zero and Succ are new types.
• They are classified by the kind Nat
• Zero Nat
• Succ Nat gt Nat
• Succ Zero Nat

20
2
A hierarchy of values, types, kinds, sorts,
1
sorts

gt
Nat
kinds

Nat gt Nat
Int
Int

Zero
Succ
types
5
5
values
21
GADT in ?mega
Zero and Succ encode the natural numbers at the
type level

• kind Nat Zero Succ Nat
• data Even n
• Z where n Zero
• ex m . E(Odd m)
• where n Succ m
• data Odd n
• ex m . O(Even m)
• where n Succ m

Even and Odd are proofs constructors
22

• Z Even Zero
• E Odd m -gt Even (Succ m)
• O Even m -gt Odd (Succ m)
• Note the different ranges in Z, E and O
• The types encode enforce the well formedness.

23
Removing the restriction allows indexed types

• The parameter of a type constructor (e.g. the a
  in T a) says something about the values with
  type T a
• phantom types
• indexed types
• Consider an expression language
• data Exp
• Eint Int
• Ebool Bool
• Eplus Exp Exp
• Eless Exp Exp
• Eif Exp Exp Exp
• Ex - Int variable
• Eb - Bool variable

If b then 3 else x1 (Eif Eb (Eint 3) (Eplus
Ex (Eint 1))
But, what about terms like (Eif (Eint 3)
(Eint 0) (Eint 9))
24
Imagine a type-indexed Term datatype
Note the different range types!

• Int Int -gt Term Int
• Bool Bool -gt Term Bool
• Plus Term Int -gt Term Int -gt Term Int
• Less Term Int -gt Term Int -gt Term Bool
• If Term Bool -gt Term a -gt Term a -gt Term a
• X Term Int
• B Term Bool

25
Type-indexed Data

• Benefits
• The type system disallows ill-formed Terms like
  
• (If (Int 3) (Int 0) (Int 9))
• Documentation
• With the right types, such objects act like
  proofs

26
Why is (Term a) like a proof?

• A value x of type Term a is like a judgment
• G x a
• The type systems ensures that only valid
  judgments can be constructed. Having a value of
  type Term a guarantees (i.e. is a proof of)
  that the term is well typed.

If b then 3 else x1 (If B (Int 3)
(Plus X (Int 1))
G x Int
G b Bool
G 1Int
G xInt
G 3Int
G x1Int
G bBool
G if b then 3 else x1 Int
27
Type-indexed Terms

• data Term a
• Int Int where aInt
• Bool Bool where aBool
• Plus (Term Int) (Term Int) where aInt
• Less (Term Int) (Term Int) where aBool
• If (Term Bool) (Term a) (Term a)
• X where a Int
• B where a Bool
• Int forall a.(aInt) gt Int -gt Term a
• We can specialize this kind of type to the ones
  we want
• Int Int -gt Term Int
• Bool Bool -gt Term Bool
• Plus Term Int -gt Term Int -gt Term Int
• Less Term Int -gt Term Int -gt Term Bool
• If Term Bool -gt Term a -gt Term a -gt Term a
• X Term Int

28
Problem Type Checking

• How do we type pattern matching?
• case x of
• (Int n)Term Int -gt . . .
• (Bool b)Term Bool -gt . . .
• What type is x?
• Is it Term Int
• Or is it Term Bool

29
Obligations and Asumptions
data Term a Int Int where aInt Bool
Bool where aBool . . .

• Using a Constructor incurs an Obligation
• (Int 3)Term aShow aInt
• (Bool true)Term aShow aBool
• Pattern matching allows the system to make some
  Assumptions
• case xTerm a of
• (Int n)Term Int -gtAssume aInt. . .
• (Bool b)Term Bool -gtAssume aBool. . .

30
Programming

• eval Term a -gt (Int,Bool) -gt a
• eval (Int n) env n
• eval (Bool b) env b
• eval (Plus x y) env eval x env eval y env
• eval (Less x y) env eval x env lt eval y env
• eval (If x y z) env
• if (eval x env)
• then (eval y env)
• else (eval z env)
• eval X (n,b) n
• eval B (n,b) b

31
Type Checking

• eval Term a -gt(Int,Bool) -gt a
• eval (Less x y) env
• Assume aBool eval x env lt eval y env
• Less(aBool)gtTerm Int -gt Term Int -gt Term Bool
• x Term Int
• y Term Int
• (eval x) Int
• (eval y) Int
• (eval x lt eval y) Bool

Assume aBool in this context
32
Basic approach

• Data is a parameterized generalized-algebraic
  datatype
• It is indexed by some semantic property
• New Kinds introduce new types that are used as
  indexes
• Programs use types to maintain semantic
  properties
• We construct values that are proofs of these
  properties
• The equality constrained types make it possible

33
Constructing proofs at runtime

• Suppose we want to read a string from the user,
  and interpret that string as an expression.
• What if the user types in an expression of the
  wrong type?
• Build a proof that the term is well typed for the
  context in which we use it

34
data Exp Eint Int Ebool Bool Eplus Exp
Exp Eless Exp Exp Eif Exp Exp Exp Ex
Eb

• test IO ()
• test
• do text lt- readln
• expExp lt- parse text
• case typCheck exp of
• Pair Rint x -gt
• print (show (eval x 2))
• Pair Rbool y -gt
• if (eval y)
• then print True
• else print False"
• Fail -gt error "Ill typed term"

A dynamic test of a static property!
35
Representation Types

• data Rep t
• Rint where tInt
• Rbool where tBool
• Rep is a representation type. It is a normal
  first class value (at run-time) that represents a
  static (compile-time) type.
• There is a 1-1 correspondence between Rint and
  Int, and Rbool and Bool. If x Rep t then
• knowing the shape of x determines its type,
• knowing its type determines its shape.
• One cant overemphasize the importance of this!

36
Untyped Terms and Judgments

• data Exp
• Eint Int
• Ebool Bool
• Eplus Exp Exp
• Eless Exp Exp
• Eif Exp Exp Exp
• Ex
• Eb
• data Judgment
• Fail
• exists t . Pair (Rep t) (Term t)

37
Constructing a Proof

• typCheck Exp -gt Judgment
• typCheck (Eint n) Pair Rint (Int n)
• typCheck (Ebool b) Pair Rbool (Bool b)
• typCheck Ex Pair Rint X
• typCheck Eb Pair Rbool B
• typCheck (Eplus x y)
• case (typCheck x, typCheck y) of
• (Pair Rint a, Pair Rint b)
• -gt Pair Rint (Plus a b)
• _ -gt Fail

38
More cases

• typCheck (Eless x y)
• case (typCheck x, typCheck y) of
• (Pair Rint a, Pair Rint b)
• -gt Pair Rbool (Less a b)
• _ -gt Fail
• typCheck (Eif x y z)
• case (typCheck x, typCheck y, typCheck z) of
• (Pair Rbool a, Pair Rint b, Pair Rint c)
• -gt Pair Rint (If a b c)
• (Pair Rbool a, Pair Rbool b, Pair Rbool c)
• -gt Pair Rbool (If a b c)
• _ -gt Fail

39
Our Original Goals

• Build heterogeneous meta-programming systems
• Meta-language ? object-language
• Type system of the meta-language guarantees
  semantic properties of object-language
• Experiment with Omega
• Finding new uses for the power of the type system
• Translating existing language-based ideas into
  Omega
• staged interpreters
• proof carrying code
• language-based security

40
Serendipity

• ?megas type system is good for statically
  guaranteeing all sorts of properties.
• Lists with statically known length
• RedBlack Trees
• Binomial Heaps
• Dynamic Typing
• Proof Carrying Code

41
Conclusion

• Stating static properties is a good way to think
  about programming
• It may lead to more reliable programs
• The compiler should ensure that programs maintain
  the stated properties
• Generalizing algebraic datatypes make it all
  possible
• Ranges other than T a
• a becomes an index describing a static property
  of xT a
• New kinds let a have arbitrary structure
• Computing over a is sometimes necessary

42
Contributions

• Logical Framework ideas translated into
  everyday programming idioms.
• Manipulating strongly-typed object languages in a
  semantics-preserving manner.
• Implementation of Cheney and Hinzes equality
  qualified types in a functional programming
  language.
• Use of new kinds to build new kinds of index
  sets.
• Representation (or Singleton) Types as a way to
  seamlessly switch between static and dynamic
  typing.
• Demonstration
• Show some practical techniques
• Lots of examples
• Resource www.cs.pdx.edu/sheard
• Including Emir Pasalics Thesis.

43
Related Work

• Logical Frameworks LF Bob Harper et. Al
• Refinement types Frank Pfenning
• Inductive Families
• In type theory -- Peter Dybjer
• Epigram -- Zhaohui Luo, James McKinna, Paul
  Callaghan, and Conor McBride
• First-class phantom types -- Cheney and Hinze
• Guarded Recursive Data Types
• Hong Wei Xi and his students
• Guarded Recursive Datatype Constructors
• A Typeful Approach to Object-Oriented Programming
  with Multiple Inheritance
• Meta-Programming through Typeful Code
  Representation
• Constraint-based type inference for guarded
  algebraic data types -- Vincent Simonet and
  François Pottier
• A Systematic Translation of Guarded Recursive
  Data Types to Existential Types -- Martin
  Sulzmann
• Polymorphic typed defunctionalization -- Pottier
  and Gauthier.
• Towards efficient, typed LR parsers -- Pottier
  and Régis-Gianas.
• First Class Type Equality
• A Lightweight Implementation of Generics and
  Dynamics -- Hinze and Cheney
• Typing Dynamic Typing -- Baars and Swierstra
• Type-safe cast Functional pearl -- Wierich

44
Step 2 Using Staging

• Suppose you are writing a document retrieval
  system.
• The user types in a query, and you want to
  retrieve all documents that meet the query.
• The query contains information not known until
  run-time, but which is constant across all
  accesses in the document base.
• E.g.
• Width Indent lt Depth Keyword Naval

45
Width Indent lt Depth Keyword Naval

• If Width and Indent are constant across all
  queries, But Depth and Keyword are fields of each
  document
• How can we efficiently build an execution engine
  that translates the users query (typed as a
  String) into executable code?

46
Code in Omega

• promptgt 5 5
• 5 5 Code Int
• promptgt run 5 5
• 10 Int
• promptgt let x 23
• X
• promptgt let y 56 - x
• Y
• promptgt y
• 56 - 23 Code Int

47
Dynamic values

• data Dyn x
• Dint Int where x Int
• Dbool Bool where x Bool
• Dyn (Code x)
• dynamize Dyn a -gt Code a
• dynamize (Dint n) lift n
• dynamize (Dbool b) lift b
• dynamize (Dyn x) x

48
translation

• trans Term a -gt (Dyn Int,Dyn Int) -gt Dyn a
• trans (Int n) (x,y) Dint n
• trans (Bool b) (x,y) Dbool b
• trans X (x,y) x
• trans Y (x,y) y
• trans (Plus a b) xy
• case (trans a xy, trans b xy) of
• (Dint m,Dint n) -gt Dint(mn)
• (m,n) -gt Dyn (dynamize m) (dynamize n)
  
• trans (If a b c) xy
• case trans a xy of
• (Dbool test) -gt if test then trans b xy
  else trans c xy
• (Dyn test) -gt
• Dyn if test
• then (dynamize (trans b xy))
• else (dynamize (trans c xy))

49
Applying the translation

• -- if 3 lt 5 then (x (5 2)) else y
• x1 If (Less (Int 3) (Int 5))
• (Plus X (Plus (Int 5) (Int 2)))
• Y
• w term
• \ x y -gt
• (dynamize(trans term
• (Dyn x ,Dyn y )))
  
• -- w x1
• -- \ x y -gt x 7 Code (Int -gt Int -gt Int)

50
Examples we have done

• Typed, staged interpreters
• For languages with binding, with patterns,
  algebraic datatypes
• Type preserving transformations
• Simplify Exp t -gt Exp t
• Cps Exp t -gt Exp trans t
• Proof carrying code
• Data Structures
• Red-Black trees, Binomial Heaps , Static length
  lists
• Languages with security properties
• Typed self-describing databases, where meta data
  in the database describes the database schema
• Programs that slip easily between dynamic and
  statically typed sections. Type-case is easy to
  encode with no additional mechanism

51
Some other examples

• Typed Lambda Calculus
• A Language with Security Domains
• A Language which enforces an interaction protocol

52
Typed lambda CalculusExp with type t in
environment s

• data V s t
• ex m . Z where s (t,m)
• ex m x . S (V m t) where s (x,m)
• data Exp s t
• IntC Int where t Int
• BoolC Bool where t Bool
• Plus (Exp s Int) (Exp s Int) where t Int
• Lteq (Exp s Int) (Exp s Int) where t Bool
• Var (V s t)
• Example Type
• Plus forall s t . (tInt) gt
• Exp s Int -gt Exp s Int -gt Exp
  s t

53
Language with Security DomainsExp with type t in
env s in domain d

• kind Domain High Low
• data D t
• Lo where t Low
• Hi where t High
• data Dless x y
• LH where x Low , y High
• LL where x Low, y Low
• HH where x High, y High
• data Exp s d t
• Int Int where t Int
• Bool Bool where t Bool
• Plus (Exp s d Int) (Exp s d Int) where t
  Int
• Lteq (Exp s d Int) (Exp s d Int) where t
  Bool
• forall d2 . Var (V s d2 t) (Dless d2 d)

54
Language with interaction prototcolCommand with
store St starting in state x, ending in state y

• kind State Open Closed
• data V s t
• forall st . Z where s (t,st)
• forall st t1 . S (V st t)
• where s (t1,st)
• data Com st x y
• forall t . Set (V st t) (Exp st t) where xy
• forall a . Seq (Com st x a) (Com st a y)
• If (Exp st Bool) (Com st x y) (Com st x y)
• While (Exp st Bool) (Com st x y) where x y
• forall t . Declare (Exp st t) (Com (t,st) x
  y)
• Open where x Closed, y Open
• Close where x Open, y Closed
• Write (Exp st Int) where x Open, y Open