Patterns

Pattern Matching &
Predicate Dispatch

Thursday, August 18, 11 1

๏ Dynamic programming languages are
powerful, productive



๏ Errors from dynamic typing are not fun




๏ Too much type information is “trapped
inside”




๏ Too much type information is “trapped
inside”

๏ We can do better without resorting to
static types


closed versus open

(cond
(map? x) ...
(vector? x) ...
(list? x) ...
:else ...)


better but...

(extend-type IPersistentMap
...)

(extend-type IPersistentVector
...)

(extend-type IPersistentList
...)


we want to enumerate what is
allowed

duck-typing doesn’t let us specify a
specific set of things which are
allowed


allowed

allowed

๏ Types are often too coarse a granularity
for the kind of dispatch we would like to
specify


allowed

allowed

specify

๏ Duck-typing can be a source of pain.


allowed

allowed

specify

๏ Duck-typing can be a source of pain.

๏ Pre and post conditions are also
“trapped inside” functions


we often reach into a
data structure to pull it
part ...
but isn’t this just like
what we do w/ cond +
map? vector?

(cond
(= (first s) 1) ...
(= (first s) 2) ...
(= (second s) :foo) ...
...)


destructuring does make
it more convenient... but
something is still missing

(let [[x & r] s]
(cond
(= x 1) ...
(= x 2) ...
(= (second s) :foo) ...
...))


this where we are today
with match...

we’ll talk about this but
note that this is very
much a chocolate fudge
machine infused cond

(match [x]
[[1 & r]] ...
[[2 & r]] ...
[[_ :foo & r]] ...
...)


but this is where we’d
like to be

(extend-pred foo [[1 & r]] ...)

(extend-pred foo [[2 & r]] ...)

(extend-pred foo [[_ :foo & r]] ...)


Goals


Goals
๏ As fast or faster than destructuring for
matches with few cases


Goals
๏ Pattern matching should follow
destructuring syntax when possible


Goals
๏ Extensible (!)


Goals
๏ Extensible (!)
๏ Testbed for predicate dispatch


pattern matching


๏ Popular feature among functional
programming languages - Standard ML,
Erlang, Haskell, OCaml, Scala



๏ Literature on eﬃcient pattern matching
in the ML language family is extensive



๏ Literature on eﬃcient pattern matching
in the ML language family is extensive

๏ Decisions trees and backtracking
automata popular approaches


๏ Pattern matching in ML restricts the
types in the columns


๏ Pattern matching in ML restricts the
types in the columns

๏ We want pattern matching to work
across types


Luc Maranget


๏ Compiling Pattern Matching to Good
Decision Trees


Decision Trees

๏ Simple compilation algorithm


Decision Trees

๏ Simple compilation algorithm

๏ Big idea is choosing which column to
test based on the notion of “necessity”
from lazy pattern matching


How it works in match


false and true are literals, _ is a
wildcard pattern, it will match
anything

(match [x y z]
[_ false true] 1
[false true _ ] 2
[_ _ false] 3
[_ _ true] 4
:else 5)


x y z
[_ f t] 1
[f t _] 2
[_ _ f] 3
[_ _ t] 4
[_ _ _] 5


top down evaluation
order, we don’t need to
test anything below a
wildcard

x y z
[_ f t] 1
[f t _] 2
[_ _ f] 3
[_ _ t] 4
[_ _ _] 5


y column has the largest
useful (non-wildcard)
patterns

y

[_ f t] 1
[f t _] 2
[_ _ f] 3
[_ _ t] 4
[_ _ _] 5


swap y column to the
front, now we need to
specialize

y x z
[f _ t] 1
[t f _] 2
[_ _ f] 3
[_ _ t] 4
[_ _ _] 5


Matrix Specialization


set constructors in the y
column

#{t f}


we remove the rows that

x z
don’t match the value for
y. we drop the y column.

here are the next

2
pattern matrices for the
t wo values of y
[f _]
t [_
[_
f]
t]
3
4
[_ _] 5

x z
[_ t] 1

f [_
[_
f]
t]
3
4
[_ _] 5


rinse, repeat


we can take that
process and produce a
nested conditional.
(cond note that the order
(= y false) (cond testing matches
what we saw in
(= z false) (let [] 3) previous slides
(= z true) (let [] 1)
:else (throw (java.lang.Exception. "Found
FailNode")))
(= y true) (cond
(= x false) (let [] 2)
:else (cond
(= z false) 3
(= z true) 4
:else (throw
(java.lang.Exception.
"Found FailNode"))))
:else (cond
(= z false) (let [] 3)
(= z true) (let [] 4)
:else (throw (java.lang.Exception. "Found FailNode"))))


๏ a pattern matrix is composed of pattern
rows


rows

๏ pattern rows contain all the speciﬁed
patterns in addition to an action


rows

๏ pattern rows contain all the speciﬁed
patterns in addition to an action

๏ pattern rows must all be of the same size
(equal number of patterns)


๏ Patterns in match are implemented as
deftypes


deftypes

๏ The key protocol for a pattern to extend
is ISpecializeMatrix which deﬁnes a
single protocol fn - specialize-matrix


deftypes

๏ The key protocol for a pattern to extend
is ISpecializeMatrix which deﬁnes a
single protocol fn - specialize-matrix

๏ The pattern produces the new matrix
after specialization. This may involve
introducing new occurrences.


what are occurrences?

y x z
[f _ t]
[t f _]
[_ _ f]
[_ _ t]


consider this seq pattern
match

(match [x]
[[1 & r] 1
[[2 & r] 2
[[3 & r] 3)


x
[[1 & r]]
[[2 & r]]
[[3 & r]]


when the matrix is specialized by
SeqPattern we get this new pattern
matrix. We have the occurrence that
represents the head of the list and
the tail of the list.

xh xt
[1 r]
[2 r]
[3 r]


The Decision Tree

occurrences will end up
being represented as
switch nodes

1

2
SwitchNodex
3

fail


๏ We end up with a tree of switch nodes.
Each switch nodes represents a
occurrence/binding and a multiway test
which points to other switch nodes, leaf
nodes, or fail nodes.


๏ We end up with a tree of switch nodes.
Each switch nodes represents a
occurrence/binding and a multiway test
which points to other switch nodes, leaf
nodes, or fail nodes.

๏ This is the decision tree.


Examples


Seq pattern matching

note that the length of the
seq patterns do no matter!

(match [x]
[[1] :a0
[[1 2]] :a1
[[1 2 nil nil nil]] :a2
:else :a3)


note the rest pattern syntax
support just like destructuring.

notice that we can introduce
bindings anywhere we would
use a wildcard

(match [x]
[[1]] :a0
[[_ 2 & [a & b]]] [:a1 a b]
:else :a2)


map pattern matching

(match [x]
[{_ :a 2 :b}] :a0
[{1 :a _ :c}] :a1
[{3 :c _ :d 4 :e}] :a2
:else :a3)


we can restrict that only
maps with the exact keys will
match

(match [x]
[{_ :a 2 :b :only [:a :b]}] :a0
[{1 :a c :c}] :a1
[{3 :c d :d 4 :e}] :a2
:else :a3)


or patterns!

(match [x y z]
[[1 (3 | 4) 3]] :a0
[[1 (2 | 3) 3]] :a1
:else :a2)


Guards!

(match [y]
[[_ (a :when even?) _ _]] :a0
[[_ (b :when [odd? div3?]) _ _]] :a1
:else :a2)


sometimes you want to
match a specific
portion and bind that
to a local name

(match [v]
[[3 1]] :a0
[[([1 a] :as b)]] [:a1 a b]
:else :a2)


you can pattern match
Java classes!

(extend-type java.util.Date
IMatchLookup
(val-at* [this k not-found]
(case k
:year (.getYear this)
:month (.getMonth this)
:date (.getDate this)
:hours (.getHours this)
:minutes (.getMinutes this)
not-found)))


(let [d (java.util.Date. 2010 10 1 12 30)]
(match [d]
[{2009 :year a :month}] [:a0 a]
[{(2010 | 2011) :year b :month}] [:a1 b]))


problems


problems
๏ Pattern matching is closed


problems
๏ We want the matching to happen at the
level of our most powerful abstraction -
functions


problems
๏ We want the matching to happen at the
level of our most powerful abstraction -
functions
๏ Without open dispatch, all we have is a
chocolate fudge machine powered cond


multimethods?


problems


problems
๏ Hard coded dispatch function


problems
๏ In order to specify complex matches we
have to construct a collection


problems
๏ In order to specify complex matches we
have to construct a collection
๏ For complex matches, performance is less
than we would like


future directions


future directions

๏ Vector patterns: for any data type that
supports random access and fast
“slicing” - PersistentVector, primitive
arrays, buﬀers, etc.


future directions

๏ Vector patterns: for any data type that
supports random access and fast
“slicing” - PersistentVector, primitive
arrays, buﬀers, etc.
๏ Predicate Dispatch (huh?)


predicate dispatch


pattern matching vs.
predicate dispatch


predicate dispatch

๏ static vs. dynamic


predicate dispatch


๏ closed vs. open


predicate dispatch


๏ closed vs. open

๏ fast vs. slow (ouch)


Goals


Goals
๏ move the matching to level of function, as with
multimethods


Goals
multimethods
๏ this change is in conﬂict with the semantics of
pattern matching - pattern matching is ordered


Goals
multimethods
๏ this change is in conﬂict with the semantics of
pattern matching - pattern matching is ordered
๏ We need some way to know where to put new
pattern rows in the matrix


A Sketch


A Sketch
๏ Use core.logic to order the pattern rows


A Sketch
๏ A high performance in-memory DAG
representation of the decision tree


A Sketch
๏ A high performance in-memory DAG
representation of the decision tree
๏ Perhaps we can go the route of deftype-
inline patterns get best performance


Challenges


Challenges
๏ How much of the pattern matching
syntax can we bring over?


Challenges
๏ How close can we get to the performance
of static code?


Challenges
๏ How close can we get to the performance
of static code?
๏ Can we limit the scope of changes to
namespaces?


(defpred foo
([{a :a} 0] ...)
([{a :a} (y :when even?)] ...))

(extend-pred foo [{c :c} 3]
...)


Questions?


Patterns

Recommandé

Recommandé

Contenu connexe

En vedette

En vedette (11)

Patterns