Functional Programming is Everywhere Ilya Sergey ilyasergey.net PLMW @ ICFP 2019
2 About myself MSc Saint Petersburg State University, 2008 PhD KU Leuven, 2008-2012 Currently Associate Professor (tenure-track) at Yale-NUS College & NUS Previously Lecturer → Associate Professor at University College London Postdoc at IMDEA Software Institute Software Engineer at JetBrains
3 Functional programmer since 2005
4 Functional programmer since 2005 2005 2006 2007 2008 2010 2011
5 Functional Languages
6 The Essence of Functional Languages • Higher-order functions and closures • Algebraic Data Types • Types and Type Inference • Pattern Matching • Polymorphism • Folds • Laziness • Continuations and CPS • Point-free style • Structural Recursion • Combinator Libraries • Type Classes • Purely functional data structures • Monads Check out this year’s ICFP program…
7 This Talk Functional Programming
8 This Talk Functional Programming
9 This Talk Functional Programming Ideas λ
10 Functional Programming Ideas in… Teaching Software Engineering Research Disclaimer : personal experience
11 Functional Programming Ideas in… Teaching Software Engineering Research
12 Moore’s Law Transistor count still rising Clock speed flattening sharply
13 The Multicore Processor Sun All on the cache cache cache T2000 same chip Bus Bus Niagara shared memory
14
15 Specifications for Concurrent Data Structures
16 My research agenda since 2014 Reusable Specifications for Concurrent Data Structures
Abstract Specifications of a Stack { S = xs } { S ′ = x :: xs } push x { S = xs } { res = ⊥ ⋀ S = Nil pop() ⋁ ∃ x, xs ′ . res = x ⋀ xs = x :: xs ′ ⋀ S ′ = xs ′ } Suitable for sequential programming
Abstract Specifications of a Stack { S = xs } { S ′ = x :: xs } push x { S = xs } { res = ⊥ ⋀ S = Nil pop() ⋁ ∃ x, xs ′ . res = x ⋀ xs = x :: xs ′ ⋀ S ′ = xs ′ } Breaks composition in the presence of thread interference.
{ S = Nil } y := pop(); { y = ??? }
{ S = Nil } � � � � push 1; � � y := pop(); � � � � push 2; � � { y ∈ { ⊥ } ∪ {1, 2} } � � � �
N o p r (not thread-modular) o o f { S = Nil } r e u s e � � � � � � � � push 1; � � � � y := pop(); push 3; � � � � � � � � push 2; � � � � { y ∈ { ⊥ } ∪ {1, 2, 3} } � � � � � � � �
A reusable specification for pop? { S = Nil } y := pop(); { y = ??? }
23 The Essence of Functional Languages • Higher-order functions and closures • Algebraic Data Types • Types and Type Inference • Pattern Matching • Polymorphism • Folds • Laziness • Continuations and CPS • Point-free style • Structural Recursion • Combinator Libraries • Type Classes • Purely functional data structures • Monads
24 The Essence of Functional Languages • Higher-order functions and closures • Algebraic Data Types • Types and Type Inference • Pattern Matching • Polymorphism • Folds • Laziness • Continuations and CPS • Point-free style • Structural Recursion Enablers for Modular Development • Combinator Libraries • Type Classes • Purely functional data structures • Monads
Idea: Interference- Parameterised Specifications Capture the e ff ect of self-thread , parametrise over the e ff ect of others . (aka Subjective specifications )
Atomic stack specifications { S ′ = x :: xs } { S = xs } push x
Atomic stack specifications xs x :: xs t k → “abstract timestamp”
} t k → t k+1 → t k+2 → t k+3 → abstract time increases at {z t k+4 → every concrete push/pop operation …… t k+n → |
Changes by this thread Changes by other threads t k → t k+1 → t k+2 → t k+3 → t k+4 → …… t k+n →
Subjective stack specifications Sergey, Nanevski, Banerjee [ESOP’15] • H s — “ghost history” of my pushes/pops to the stack • H o — “ghost history” of pushes/pops by all other threads { H s = ∅ } λ H o . pick ( pushed (H o )) y := pop(); { y = ⊥ ⋁ y = v , where v ∈ pushed (H o ) } | {z } what I popped depends on what the others have pushed
{ S = Nil } � � � � � � � � push 1; � � � � y := pop(); push 3; � � � � � � � � push 2; � � � � � � � � � � � �
{ H s = ∅ } push 1; { H s = t 1 ↦ (xs, 1 ::xs) } push 2; { H s = t 1 ↦ (xs, 1 ::xs) ⊕ t 2 ↦ (ys, 2 ::ys) }
{ H s = ∅ } push 1; { H s = t 1 ↦ (xs, 1 ::xs) } push 2; { H s = t 1 ↦ (xs, 1 ::xs) ⊕ t 2 ↦ (ys, 2 ::ys) }
{ H s = ∅ } � � push 1; { H s = ∅ } � � � � { H s = t 1 ↦ (xs, 1 ::xs) } push 3; � � � � � � push 2; { H s = t 3 ↦ (zs, 3 ::zs) } � � � � { H s = t 1 ↦ (xs, 1 ::xs) ⊕ t 2 ↦ (ys, 2 ::ys) }
{ H s = ∅ } � � � � { H s = ∅ } { H s = ∅ } � � � � push 1; � � � � y := pop(); push 3; � � � � � � � � push 2; � � � � { H s = t 3 ↦ (zs, 3 ::zs) } { y ∈ { ⊥ } ∪ pushed (H o ) } � � � � { H s = t 1 ↦ (xs, 1 ::xs) ⊕ � � � � t 2 ↦ (ys, 2 ::ys) }
{ H s = ∅ } � � � � { H s = ∅ } { H s = ∅ } � � � � push 1; � � � � y := pop(); push 3; � � � � � � � � push 2; � � � � { H s = t 3 ↦ (zs, 3 ::zs) } 3 { y ∈ { ⊥ } ∪ pushed (H o ) } � � � � { H s = t 1 ↦ (xs, 1 ::xs) ⊕ 1 � � � � t 2 ↦ (ys, 2 ::ys) } 2
{ H s = ∅ } � � � � { H s = ∅ } { H s = ∅ } � � � � push 1; � � � � y := pop(); push 3; � � � � � � � � push 2; � � � � { H s = t 3 ↦ (zs, 3 ::zs) } { y ∈ { ⊥ } ∪ { 1 , 2 , 3 } } � � � � { H s = t 1 ↦ (xs, 1 ::xs) ⊕ � � � � t 2 ↦ (ys, 2 ::ys) }
Payo ff : Verified Concurrent Libraries Sergey et al. [PLDI’15] Atomic Jayanti’s Spin-lock Ticketed lock snapshot snapshot Flat combiner Abstract lock Allocator Snapshot client FC stack Treiber stack Increment Counting Exchanger network Abstract stack Sequential stack Concurrent Graph Quiescent Quantitatively Manipulations Producer/Consumer client relaxed client
39 Functional Programming Ideas in… Teaching Software Engineering Research … for modularity and proof reuse
40 Functional Programming Ideas in… Teaching Software Engineering Research … for Modularity and Proof Reuse
Algorithmic Competitions at UCL (2016-2018) • Targeting 2nd year undergrads, team work • One week-long • Should involve math and programming • Challenging for students, but easy to assess
Algorithmic Competitions at UCL (2016-2018)
The Competitions • 2016: Art Gallery Competition • 2017: Move-and-Tag Competition • 2018: Room Furnishing
Art Gallery Competition based on: Chvátal’s Art Gallery Problem (1975)
How many guards do we really need? The answer depends on the shape of the gallery.
How many guards do we really need? The answer depends on the shape of the gallery.
How many guards do we really need?
How many guards do we really need?
How many guards do we really need?
How many guards do we really need?
Art Gallery Problem For a given gallery (polygon), find the minimal set of guards’ positions, so together the guards can “see” the whole interior.
Project: Art Gallery Competition Find the best solutions for a collection of large polygons. • 58 vertices • 5 guards
Making it Fun • Problem generator; ‣ Polygons with different “features” (convex, rectangular, etc .) • Solution checker with online feedback ‣ geometric machinery (triangulation, visibility, …) ‣ web-server • Make sure that it all works.
Making it Fun • Problem generator; ‣ Polygons with different “features” (convex, rectangular, etc .) • Solution checker with online feedback ‣ geometric machinery (triangulation, visibility, …) ‣ web-server • Make sure that it all works.
Growing polygons Primitive polygons with specific “features”
Growing polygons Seed
Growing polygons
Growing polygons
Growing polygons
Growing polygons
Growing polygons
Growing polygons
65 Can we enumerate “primitive” polygons and plug arbitrary shapes generators?
66 The Essence of Functional Languages • Higher-order functions and closures • Purely functional data structures • Types and Type Inference • Pattern Matching • Polymorphism • Folds • Laziness • Continuations and CPS • Point-free style • Structural Recursion • Combinator Libraries • Type Classes • Algebraic Data Types • Monads
Recommend
More recommend
