Eliminating Overlapping in Pattern Matching when Verifying Erlang Programs in muCRL

Eliminating Overlapping in Eliminating Overlapping in Pattern Matching when Verifying Pattern Matching when Verifying

Erlang Programs in muCRLErlang Programs in muCRL

Qiang Guo and John Derrick

Department of Computer ScienceThe University of Sheffield

Regent Court211 Portobello Street

Sheffield, S1 4DPUnited Kingdom

{Q.Guo, J.Derrick}@dcs.shef.ac.uk

The 12th International Erlang/OTP User Conference, Stockholm, Sweden, 9th-10th, November, 2006

2

An introduction to An introduction to FORSE FORSE projectproject

• FORSE (FORmally-based tool Suport for Erlang development) is a 3-year EPSRC funded project, joint between the Universities of Sheffield and Kent, UK with industrial involvement of T-Mobile and Erlang Training & Consultant Ltd.

• The principal goal is to build tools to produce a more reliable engineering process for developing Erlang programs.

• The project has three research strands: Refactoring, Model Checking and Testing.

• The presented paper illustrates some outcomes on model checking Erlang.

• Project website: http://www.dcs.shef.ac.uk/~qiang/forse/forse.htm

EUC’06

Eliminating overlapping in pattern matching when verifying Erlang programs in muCRL

http://www.dcs.shef.ac.uk/~qiang/forse/forse.htm

3

Model checkingModel checking

• Model checking is an automatic formal verification technique that has been widely used in verifying requirements and design.

• Model checking aims to establish explicit properties of design patterns that guarantee correctness of the system.

• The advantage of using model checking technique for system verification is that, when a fault is detected, the model checker can generate a counter example, which helps system developer to understand what causes the failure and provides clues for fixing the problem.

• Two ways might be considered for system verification using model checking techniques.

• In one way, a specification language in combination with a model checker is applied to obtain a correct specification that is used to write an implementation; in the other way, the source code of a program is considered as a starting point and is abstracted into a model that can be checked by a model checker.

• The second situation requires an interpretation mechanism that translates the programming language into the formal specification language used for describing the system under development.


EUC’06

4

BackgroundBackground

• Recently, verification of Erlang programs in the process algebra muCRL has been studied.

• When verifying Erlang programs in a muCRL specification, the programs are first translated into a muCRL specification.

• A Labelled Transition System (LTS) is derived via CADP tool.

• LTS is used to check the properties that the designed system should hold.


EUC’06

5

MotivationMotivation

• Benac Earle et al. studied the verification of Erlang programs in muCRL and defined a set of rules for the translation of an Erlang code into muCRL. In their work, translation rules for communication, generic server, supervision tree, functions with side-effects, higher-order functions and pattern matching are defined respectively.

• They also developed a tool set, etomcrl, which automatically translates Erlang programs into a muCRL specification.

• However, the tool set translates the pattern matching in a way where overlapping is not considered.

• This could lead to the system being represented by a faulty model.


EUC’06

6

ErlangErlang

• Erlang is a concurrent functional programming language with explicit support for real-time and fault-tolerant distributed systems.

• An Erlang program consists of a set of modules, each of which defines a number of functions.

• A module is uniquely identified by its name as an atom.• A function is uniquely identified by the module name,

function name and arity.• Erlang is a language with light-weight process. Several

concurrent process can run in the same virtual machine.• A distributed system can be constructed by connecting a

number of virtual machines.• An advantage of Erlang is that it uses design pattern (OTP).• The use of OTP reduces the complexity of system

development and testing.Eliminating overlapping in pattern matching when verifying Erlang programs in muCRL

EUC’06

7

muCRLmuCRL

• The process algebra muCRL is extended from the process algebra ACP where equational abstract data types are integrated into process specification.

• A muCRL specification is comprised of two parts: the data types and the processes.

• Processes are declared using the keyword proc.• A process may contain actions declared using the keyword act.• Data types used in mCRL are specified as the standard

abstract data types, using sorts, functions and axioms.• A number of process-algebraic operations are defined, these

being: sequential composition (.), non-deterministic choice (+), parallelism (||), encapsulation ( ), hiding ( ), renaming ( ) and recursive declarations.

• Parallel processes communicate via synchronization of actions.


EUC’06

∂

8

Translating Erlang into muCRLTranslating Erlang into muCRL

• Benac Earle et al. defined a set of translation rules.• The translation from Erlang to muCRL is performed in two stages.• First, a source to source transformation is applied.• Second, transformed code is translated into muCRL.• In muCRL, a data type Term is define for all data types defined in

Erlang.• Atoms are translated to muCRL constructors; • true and false represent the Erlang boolean; int is defined for

integers; nil for the empty list; cons for a list with an element (head) and a rest (the tail); tuple for a tuple with more than one element.

• For example, [E1,…,En] is translated to cons(E1,cons(E2,cons(…,cons(En, nil)))) and {E1,…,En} is translated to tuple(E1,tuple(E2,…,tuplenil(En))).

• High-order functions are flattened into first-order alternatives.• A Stack is used to cope with side-effect functions.


EUC’06

9

Problem of overlapping in pattern matchingProblem of overlapping in pattern matching

• However, in Benac Earle et al.’s work, pattern matching in an Erlang code is translated in a way where overlapping patterns are not considered.

• In Erlang, evaluation of pattern matching works from left to right and from top to bottom.

• When a pattern is matched, the evaluation terminates after executing the corresponding clauses.

• However, the muCRL toolset instantiator does not evaluate the rewriting rules in a fixed order.

• If there exists overlapping between two patterns in an Erlang source code, the problem occurs when translating the code into muCRL.

• This could lead to the system being represented by a faulty model.


EUC’06

10

An exampleAn example

-module(check_list).-export([check/1]).check(List)-> case List of [ ] -> empty_list;

[1|_] -> head_check; [_| 2,3] -> tail_check

end.

• If List=[1,2,3], it matches both [1|_] and [_|2,3].• In Erlang, head_check is returned;• However, muCRL toolset does not evaluate patterns in a

fixed order. The returned value could be either head_check or tail_check.


EUC’06

11

Possible solutionsPossible solutions

• Two possible ways might be considered for the elimination of overlapping in pattern matching.

• In one way, guards in the rewriting rules are applied to force the muCRL instantiator to evaluate rewriting rules in a fix order (see the next slide).

• Clara proposed the above method but did not apply it in the toolset etomcrl.

• In the other way, before translation starts, Erlang codes are transformed into ones without overlapping patterns

• Pattern matching clauses such as case are replaced with a set case functions, each of which is controlled by a guard.

• By such a way, pattern matching is forced to be evaluated in a fixed order (see slide 15).

• This work considers the use of the second strategy since it involves in less effort in modifying the source codes of etomcrl.


EUC’06

12

Applying guards in the rewriting rulesApplying guards in the rewriting rules

• Benac Earle suggested the use of guards in the muCRL specification.

• A patterns_match function is defined for the evaluation of a pattern.

• Patterns_match has three arguments: a pattern, an expression and a mapping from variable to expressions.


EUC’06

• Patterns_match returns a condition and a new mapping.

• An auxiliary function var(P) is defined to returns the logic value true if P is a variable and false otherwise.

13

Applying guards in the rewriting rulesApplying guards in the rewriting rules

• Pattern matching clauses are translated into a set of case functions guarded by a condition function .

• is the projection of• represents the mapping from {V1,…,Vi} to {V1,…,Vi}.• An example is shown in the next slide.• A case1 function is invoked when the evaluation of pattern matching

starts.• case1 calls another case function case2 when is

evaluated.• If returns true, B1 is executed and the evaluation

terminates; otherwise, case3 is called where Q2 is evaluated.• The evaluation continues until a pattern is matched.• However, the proposed method is not applied in etomcrl.


EUC’06

14

An exampleAn example


EUC’06

15

Transforming Erlang source codeTransforming Erlang source code

• In this paper, we defined a new approach to eliminate overlapping in pattern matching.

• The proposed approach rewrite an Erlang program with overlapping patterns into a counterpart program without overlapping patterns.

• In this work, a patterns_matching function is defined for pattern evaluation in the Erlang source code.

• Pattern clauses in a program such case are replaced with a series of case functions guarded by the patterns_matching function.

• In the patterns_matching, a structure splitting tree is defined in order to effectively evaluate a pattern expression.

• The use of SSTs guarantees that no overlapping will be introduced into the rewritten Erlang programs.


EUC’06

16

An ExampleAn Example


EUC’06

17

Define patterns_matching functionDefine patterns_matching function

• The problem now comes to define patterns_matching function.

• The function cannot be simply defined as shown in A and B

• Code in A will introduce new overlapping patterns in a rewritten code.

• The question is if “-” is not used as a pattern, can we find a suitable expression E such that

• Code in B will not introduce new overlapping

patterns. Syntactically, it is correct. • However, when it is executed, if no pattern is

matched, system exception will be invoked, which introduce semantic errors.

τ


EUC’06

18

Definition of an SSTDefinition of an SST

• In this work, we defined an structure splitting tree (SST) for pattern evaluation.

• An SST is a dependent tree where a datum complex type is graphically represented.

• Each node in the tree has an ID(i,j).• i indicates the layer where j the number of the node in the ith layer.• The type of a datum is distinguished by a graphic shape. • In this work, atom is represented by circle, list by square and tuple

diamond.• The tree starts with a root that contains the complete set of data and

terminates at a terminal node where the datum is either an atom or a list that contains a ``_`` character.

• In the next slide, an example is illustrated where [a,[[b|_], {c, _, d}, [_|a,c]], {[a|_], b}, b] is represented.


EUC’06

19

An example of SSTAn example of SST

• The SST of [a,[[b|_], {c, _, d}, [_|a,c]], {[a|_], b}, b]


EUC’06

20

Pattern evaluation using SSTsPattern evaluation using SSTs

• To check if pattern P1 matches P2, one can build the SSTs of P1 and P2.

• The SSTs are examined from top to bottom and from left to right.• When a node in one SST is compared with the corresponding node

in the other SST, the type of datum is first compared. • If two datum types do not match, the evaluation returns false and

terminates; otherwise, the two data are further checked.• If the datum type is atom and the values of two data are not equal,

the evaluation returns false and terminates;• Otherwise, the check of this node is finished and the process of

evaluation moves another node.• The process of evaluation continues until all nodes have been

examined.


EUC’06

21

An exampleAn example• For example, to check if P1=[a, [[b, c, d], {c, a, d},

[a, a, c]], {[a, b, c], b}, b] matches P2= [a,[[b|_], {c, _, d}, [_|a,c]], {[a|_], b}, b], one can build the SSTs of P1 and P2 respectively.

• Nodes in the SST of P1 are compared to the corresponding nodes in the SST of P2 from top to bottom and from left to right.

• The evaluation starts with the root node N(1,1).• Both root nodes contain a non-empty list, which

indicates the first layer comparison is matched.• The evaluation moves to the second layer where

N(2,1), N(2,2), N(2,3) and N(2,4) are checked in sequence.

• The evaluation continues until all nodes are checked.

• Note that when evaluation comes to the 4th layer, the checking on N(4,2) and N(4,3) should be ignored since N(4,2) of P2 contains a list whose elements matches any possible data.


EUC’06

22

AdvantagesAdvantages

• The advantage of using an SST for pattern evaluation is that it will not introduce overlapping in the rewritten Erlang codes.

• The use of an SST will not cause exception during the runtime.

• It is easy to see that evaluating the pattern of an SST is equivalent to that of searching nodes in a tree.

• A breadth-first or a depth-first search algorithm can be applied.


EUC’06

23

Comparison between two methodsComparison between two methods

• The two methods proposed to eliminate the overlapping in pattern matching are functionally equivalent, but realised at different stages.

• In the first method, elimination action is performed at the stage of translation where guards are applied in the translation rules.

• In the second method, elimination action happens before the translation starts where Erlang codes with overlapping patterns are transformed into ones without overlapping.

• Guards are applied during the transformation.• We used the second method as we can realise the task

with less effort than modifying the source code of etomcrl.


EUC’06

24

Model checking Erlang in muCRLModel checking Erlang in muCRL

• Locker programs are used to evaluate the proposed methods.

• check_list function is added to evaluate the proposed method.

• A well-formed muCRL specification is obtained after apply the etomcrl tool set to the Erlang programs.

• Total 120 states and 193 transitions are explored by CADP.

• The checking result implies that the model is correct.• This suggests that the proposed method is capable of

eliminating overlapping in pattern matching.


EUC’06

25

Model checking Erlang in muCRLModel checking Erlang in muCRL


EUC’06

26

Conclusions and the future workConclusions and the future work

• An approach is proposed to overcome the problem of overlapping in pattern matching when verifying Erlang programs in muCRL.

• The proposed approach transforms an Erlang code with overlapping patterns into one without overlapping patterns.

• Structure splitting tree (SST) is defined and applied for pattern evaluation. The use of SSTs guarantees that no overlapping will be introduced into the rewritten Erlang programs.

• The proposed approach has now been added to the toolset etomcrl.

• More case studies will be carried out to experimentally evaluate the method in the future.


EUC’06

Eliminating Overlapping in Pattern Matching when Verifying Erlang Programs in muCRL

Documents

Transcript of Eliminating Overlapping in Pattern Matching when Verifying Erlang Programs in muCRL