Functional Logic Programming in Maude...Motivation Outline 1 Motivation Why narrowing in Maude Missionaries and Cannibals Our contributions 2 Rewriting logic in a nutshell Narrowing

Functional Logic Programming in Maude

Santiago Escobar

Departamento de Sistemas Informaticos y ComputacionUniversitat Politecnica de Valencia

[email protected]

Santiago Escobar (UPV) Festschrift in Honor of Kokichi Futatsugi (SAS 2014) 1 / 49

Outline1 Motivation

Why narrowing in MaudeMissionaries and CannibalsOur contributions

2 Rewriting logic in a nutshellNarrowing versus RewritingNarrowing in Maude

3 Feature 1: Semantics of values

4 Feature 2: Non-determinism and call-time choice

5 Feature 3: Strict equality

6 Feature 4: Conditional rules

7 Feature 5: Extra variables

8 Feature 6: Constraint solving and residuation

9 Missionaries and Cannibals revisited

10 Conclusions


Motivation

Outline1 Motivation










10 Conclusions


Motivation

Functional logic programming

• Functional logic programming (FLP) combine the most importantfeatures of functional programming and logic programming

• From functional paradigm:• algebraic data types,• advanced typing,• evaluation strategies, and• higher-order functions

• From logic paradigm:• logical variables,• computing with partial information,• constraint solving, and• nondeterministic search for solutions

• Functional logic programming in Maude:• logical variables, computing with partial information, and constraint

solving• reasoning modulo equational properties, advanced data types,

order-sorted typing, efficient equational evaluation


Motivation

Functional logic programming: Narrowing

• Originally introduced for automated theorem proving (Slagle, 1974)

• Mechanism for solving equational unification problems (Fay, 1979)

• Functional logic languages (Antoy, Echahed, Hanus, 2000)

• Symbolic reachability problems (Meseguer, Thati, 2007)

• Important applications:• termination (Schneider-Kamp et al., 2009)• program transformation (Alpuente, Ballis, Falaschi, 2010)• cryptographic protocols (Escobar, Meadows, Meseguer, 2006)• equational unification (Escobar, Sasse, Meseguer, 2012)


Motivation Why narrowing in Maude

Outline

1 MotivationWhy narrowing in MaudeMissionaries and CannibalsOur contributions



Why rewriting logic (Maude)?

1 Models and formal specification are easily written in Maude(simplicity, expressiveness, and performance)

2 Rewriting modulo associativity, commutativity and identity

3 Differentiation between concurrent and functional fragments of amodel

4 Order-sorted and parameterized specifications

5 Infrastructure for formal analysis and verification (including searchcommand, LTL model checker, theorem prover, etc.)

6 Reflection (meta-modeling, symbolic execution, building tools)

7 Models of computation (λ-calculi, π-calculus, petri nets, CCS),Programming languages (Java, Haskell, Prolog), Distributedalgorithms and systems (real-time, probabilistic), Biological systemsin Maude



Why unification and narrowing in Maude?

1 Automated reasoning about models and formal specification areeasily written in Maude by using logical variables and its groundinstances

2 Unification and narrowing modulo associativity, commutativity andidentity

3 Differentiation between concurrent and functional fragments of amodel is lifted to differentiation between symbolic models andequational reasoning.

4 Infrastructure for formal analysis and verification could be lifted tosymbolic versions (search to symbolic reachability, LTL modelchecker to logical LTL model checker, theorem prover to advancedtheorem prover, etc.)

5 Reflection (new tools based on unification or narrowing, for instance,confluence checker, coherence checker, termination tools)

6 Functional logic programming



Current applications• Maude-NPA. Cryptographic protocol analysis tool based on symbolic

reachability analysis using narrowing and variants.

• Tamarin. ETH Zurich Cryptographic protocol analysis tool usingvariant-based unification.

• CRC&ChC. Maude Coherence and Confluence checker thatcomputes critical pairs using narrowing and variant generation.

• MTT: Maude Termination Tool that computes approximations oftermination dependency graphs using variant generation.

• BPM. Business process modeling using symbolic reachability.

• Testing. Narrowing-based test case generation.

• Theorem proving. Narrowing-based Theorem Proving

• Decision procedures. Superposition-Based Decision Proceduresbased on narrowing in Maude.

• Fold/unfold. Fold/unfold transformations using narrowing.

• Maude Invariant Analyzer tool. Safety properties

• Unification: homomorphism, xor, variant-based unification


Motivation Missionaries and Cannibals

Outline




Missionaries and Cannibals (Goguen, Meseguer, 1984)module MAC[T :: MACTH] using NAT, TRIPLIST = LIST[trip] ispredsboatok : tripsolve, good : triplist

fnsboat : pred -> triplb,rb : triplist -> psetmset,cset : pset -> pset

varsPS:pset, L:triplist, P:person, T:trip

axiomsboatok(boat(PS)) :- # PS = 1.boatok(boat(PS)) :- # PS = 2.mset(PS) = PS /\ m0.cset(PS) = PS /\ c0.lb(nil) = m0 + c0.rb(nil) = empty.lb(L * boat(PS)) = lb(L) - PS :- even # L.rb(L * boat(PS)) = rb(L) + PS :- even # L.rb(L * boat(PS)) = rbQ - PS :- odd # L.lb(L * boat(PS)) = lb(L) + PS :- odd # L.good(L * T) :- # cset(lb(L * T)) =< # mset(lb(L * T)) or mset(lb(L * T)) = 0,

# cset(rb(L * T)) =< # mset(rb(L * T)) or mset(rb(L * T)) = 0,good(L), boatok(T).

good(nil).solve(L) :- good(L), lb(L) = empty.

endmod MAC



Notes on the MAC example

• Original program had an error• Number of cannibals lower than or equal to number of missionaries

in both sides unless there is no missionary• Discovered thanks to narrowing-based executability in Maude.

• Equational properties (beyond existing FLP languages)

• Order-sorted properties (beyond existing FLP languages)

• Logic predicates translated into functions of sort Success

• Semantics of values (for addition, for logic predicates, etc)

• Conditional rules (for conditions of logic predicates)

• Constraint solving for # cset(lb(L * T)) =< # mset(lb(L * T))

• Strict equality for # PS = 1

• No non-determinism (typical FLP)

• No extra variables (typical FLP)

• No residuation (typical FLP)


Motivation Our contributions

Outline



Motivation Our contributions

Features of FLP

Different features of FLP considered for Maude:

• a semantics of values

• non-determinism

• conditional rules

• strict equality

• extra variables

• constraint solving

• residuation

Different features of FLP not considered for Maude:

• lazy evaluation

• search commands in FLP

• meta-programming


Rewriting logic in a nutshell

Outline1 Motivation










10 Conclusions




A rewrite theory is

R = (Σ, Ax] E, R), with:

1 (Σ, R) a set of rewrite rules of the form t→ s(i.e., system transitions)

2 (Σ, Ax] E) a set of equational properties of the form t = s(i.e., E are equations and Ax are axioms such as ACU)

Intuitively, R specifies a concurrent system, whose states are elements ofthe initial algebra TΣ/(Ax]E) specified by (Σ, Ax] E), and whoseconcurrent transitions are specified by the rules R.




mod VENDING-MACHINE is

sorts Coin Item Marking Money State .

subsort Coin < Money .

op empty : -> Money .

op : Money Money -> Money [assoc comm id: empty] .

subsort Money Item < Marking .

op : Marking Marking -> Marking [assoc comm id: empty] .

op < > : Marking -> State .

ops $ q : -> Coin .

ops cookie cap : -> Item .

var M : Marking .

rl [add-$] : < M > => < M $ > .

rl [add-q] : < M > => < M q > .

rl [buy-c] : < M $ > => < M cap > .

rl [buy-a] : < M $ > => < M cookie q > .

eq [change]: q q q q = $ [variant] .

endm




Maude> search [1] < $ q q q > =>* < cookie cap St:Marking > .

Solution 1 (state 12) states: 13 rewrites: 22

St:Marking --> empty

Maude> show path 3 .

state 0, State: < $ q q q >

===[ rl < $ M > => < M q cookie > [label buy-a ] . ]===>

state 4, State: < $ cookie >

===[ rl < $ M > => < cap M > [label buy-c ] . ]===>

state 12, State: < cookie cap >

Maude> reduce q q q q q q q .

rewrites: 1 in 0ms cpu (0ms real) (1000000

rewrites/second)

result Money: $ q q q


Rewriting logic in a nutshell Narrowing versus Rewriting

Outline




Rewriting modulo

Rewriting is

Given (Σ, Ax] E, R), t→R,(Ax]E) s if there is

• a non-variable position p ∈ Pos(t);• a rule l→ r in R;

• a matching σ (E-normalized and modulo Ax) such thatt|p =(Ax]E) σ(l), and s = t[σ(r)]p.

Ex: < $ q q q > → < $ cookie >using “rl < M $ > => < M cookie q > .”modulo AC of symbol “ ”

Ex: < q q q q > → < cap >using “rl < M $ > => < M cap > .”modulo simplification with q q q q = $ and AC of symbol “ ”



Narrowing modulo

Narrowing is

Given (Σ, Ax] E, R), t σ,R,(Ax]E) s if there is

• a non-variable position p ∈ Pos(t);• a rule l→ r in R;

• a unifier σ (E-normalized and modulo Ax) such thatσ(t|p) =(Ax]E) σ(l), and s = σ(t[r]p).

Ex: < X q q > < $ cookie >using “rl < M $ > => < M cookie q > .”using substitution {X 7→ $ q} modulo AC of symbol “ ”

Ex: < X q q > < cap >using “rl < M $ > => < M cap > .”using substitution {X 7→ q q}modulo simplification with q q q q = $ and AC of symbol “ ”


Rewriting logic in a nutshell Narrowing in Maude

Outline




Narrowing in Maude 2.6

Narrowing generalizes term rewriting by allowing free variables in termsand by performing unification instead of matching in order to(non–deterministically) reduce a term.

1 Narrowing + simplification (for built-in operators and equationalsimplification)

2 Frozen arguments, similar to the context-sensitive narrowing of S.Lucas.

3 Extra variables in right hand sides of the rules for functional logicprogramming features (e.g. constraint programming andinstantiation search).



Narrowing Search Command in Maude

Full Maude provides a narrowing-based search command of the form:

16.4. THE NARROWING SEARCH COMMAND 389

We recall again that the equations E in the system module are disregarded for narrowingpurposes. However, they are applied for simplification after each narrowing step, as it is per-formed in Maude for rewriting. Recall, again, that this combination of one narrowing stepfollowed by equational simplification is not complete. A full treatment of rules, equations, andaxioms for narrowing is outside the scope of the present implementation and is left for futurework.

Frozen arguments (see Section 4.4.9) are allowed for narrowing, as for rewriting, and aregiven the standard meaning of not allowing any narrowing step below such frozen arguments(just as in the context-sensitive narrowing of [68]).

Furthermore, we do not consider any narrowing strategy at all for solving reachabilityproblems, i.e., all positions in a term with an admissible R,Ax-narrowing step are explored.

16.4 The narrowing search command

Given a system module !ModId ", the user can give to Full Maude a search command of theform:

(search [ n, m ] in !ModId " : !Term-1 " !SearchArrow " !Term-2 " .)

where:

• n is an optional argument providing a bound on the number of desired solutions;

• m is another optional argument stating the maximum depth of the search;

• the system module !ModId " where the search takes place can be omitted if it is the currentone;

• !Term-1 " is the starting non-variable term, which may contain variables;

• !Term-2 " is the term specifying the pattern that has to be reached, with variables possiblyshared with !Term-1 ";

• !SearchArrow " is an arrow indicating the form of the narrowing proof from !Term-1 "until !Term-2 ":

– ~>1 means a narrowing proof consisting of exactly one step,

– ~>+ means a narrowing proof consisting of one or more steps,

– ~>* means a narrowing proof consisting of none, one, or more steps, and

– ~>! indicates that only strongly irreducible final states are allowed, i.e., states thatcannot be further narrowed; note that this is stronger than requiring states thatcannot be rewritten.

The one step arrow ~>1 is an abbreviation for the one-or-more steps arrow ~>+ with thedepth bound m set to 1.

Consider, for example, the following variant of the vending machine for buying apples (a)or cakes (c) with dollars ($) and quarters (q) used in di!erent parts of the manual, where nowthe rules are explicitly coherent and the lefthand sides are non-variable terms (this theory doesindeed satisfy the completeness requirements for reachability mentioned in [84] and Section 16.2above):

• n is the bound on the desired reachability solutions

• m is the maximum depth of the narrowing tree

• Term-1 is not a variable but may contain variables

• Term-2 is a pattern to be reached

• SearchArrow is either ˜>1, ˜>+, ˜>*, ˜>!

• ˜>! denotes strongly irreducible terms or rigid normal forms.

• Implemented in Full Maude (no Core Maude yet).



Narrowing Search Command in Maude

mod VENDING-MACHINE issorts Coin Item Marking Money State .subsort Coin < Money .op empty : -> Money .op : Money Money -> Money [assoc comm id: empty] .subsort Money Item < Marking .op : Marking Marking -> Marking [assoc comm id: empty] .op < > : Marking -> State .ops $ q : -> Coin .ops cookie cap : -> Item .var M : Marking .rl [add-$] : < M > => < M $ > .rl [add-q] : < M > => < M q > .rl [buy-c] : < M $ > => < M cap > .rl [buy-a] : < M $ > => < M cookie q > .eq [change]: q q q q = $ [variant] .

endm

Maude> (search [,4] in VENDING-MACHINE : < M:Money > ˜>* < cookie cap > .)Solution 1M:Money --> $ q q q


Feature 1: Semantics of values

Outline1 Motivation










10 Conclusions



Semantics of values

• Functional logic programming inherits the semantics of values fromfunctional programming

• We are interested in reachability problems t→∗ t′ where t is stronglyirreducible (variable, constant).

Program: double(x)→ x + x Query 1: double(1)→∗ xAnswer: {x 7→ 2}Query 2: double(1 + 2)→∗ xAnswer: {x 7→ 6}



Computed answers?

• Functional logic programming does not have to inherit a semanticsof computed answers from logic programming

• Differences between semantics of values with and without computedanswers:

Program 1: zero(x)→ 0 Query 1: zero(x)→∗ yAnswer: {y 7→ 0}

Program 2: zero(x)→ 0 Query 1: zero(x)→∗ yzero(0)→ 0 Answer 1: {y 7→ 0}

Answer 2: {y 7→ 0, x 7→ 0}


Feature 2: Non-determinism and call-time choice

Outline1 Motivation










10 Conclusions



Call-time choice

• Functional logic programming inherits non-deterministiccomputations and search from logic programming

Program: coin→ 0 Query: double(coin)→∗ xcoin→ 1 Asnwer 1: x 7→ 0 (Run-time & call-time choice)

Asnwer 2: x 7→ 1 (Run-time choice)Asnwer 3: x 7→ 1 (Run-time choice)Asnwer 4: x 7→ 2 (Run-time & call-time choice)

• Correspondence with variable sharing when non-determinism ispresent and graph narrowing

• Standard semantics in functional logic community

• Bizarre behaviour with demand-driven evaluation



Call-time simulated

• Maude can simulate run-time and call-time choice thanks to itsmore elaborated notion of a constructor symbol and kind-extendedsignature.

sort Nat .

op 0 : -> Nat [ctor] . op 0 : -> [Nat] .

op s_ : Nat -> Nat [ctor] . op s_ : [Nat] -> [Nat] .

vars N M : Nat . vars Nx Mx : [Nat] .

op _+_ : [Nat] [Nat] -> [Nat] . op coin : -> [Nat] .

rl 0 + Mx => Mx . rl coin => 0 .

rl s Nx + Mx => s (Nx + Mx) . rl coin => s 0 .

op doubleR : [Nat] -> [Nat] . op doubleC : Nat -> [Nat] .

rl doubleR(Nx) => Nx + Nx . rl doubleC(N) => N + N .

• search doubleR(coin) =>! N:[Nat] . run-time choice (0,1,1,2)

• search doubleC(coin) =>! N:[Nat] . call-time choice (0,2)


Feature 3: Strict equality

Outline1 Motivation










10 Conclusions



Strict equality

• A semantics of values implies an equality operator on data termsinstead of a syntactic equality.

• Equality in Maude is syntactic (modulo axioms) but not semantic.

search coin == 0 =>* true . has no solution

• Strict equality usually defined on constructor symbols only

f (X1, . . . , Xn) =:= g(Y1, . . . , Ym) → false if f 6= g, n ≥ 0, m ≥ 0c =:= c → true

f (X1, . . . , Xn) =:= f (Y1, . . . , Yn) → X1=:=Y1 and · · · and Xn=:=Yn if fn > 1

• However this is a built-in operator in FLP languages ...



Strict equality simulated

• Strict equality added to every functional logic program in Maude

• New sort Success and a new symbol success are defined in Maude.

• New equality symbol =:= is defined by a rule with repeated variable.

• Symbol =:= is defined only for data sorts (e.g. Nat) instead of kind(e.g. [Nat]) reserved for defined symbols, ensuring a semantics ofvalues rather than matching any term.

sort Success .

op success : -> Success [ctor] .

op _=:=_ : Nat Nat -> [Success] [comm] .

rl X:Nat =:= X:Nat => success .

search coin =:= 0 =>* success . has solution


Feature 4: Conditional rules

Outline1 Motivation










10 Conclusions



Conditional rules

• Conditional rules are restricted to expressions of the form t =:= t′.sort NatSet .

op empty : -> NatSet . subsort Nat < NatSet .

op _;_ : NatSet NatSet -> NatSet [assoc comm id: empty] .

vars N E : Nat . var NS : NatSet .

op member : Nat NatSet -> [Bool] .

rl member(E, empty) => false .

crl member(E, N ; NL) => true if E =:= N == true .

• We assume that only the successful case of a condition is valid(avoid problems of negation as in logic programming).



Conditional rules

• Use standard transformation in functional logic languages (e.g.Curry) to use a conditional symbol >> with restricted evaluation.

op _>>_ : [Success] [Nat] -> [Nat] [frozen (2) strat (1 0)] .

rl success >> X:[Nat] => X:[Nat] .

• Program member now is transformed into

op member : Nat NatSet -> [Bool] .

rl member(E, empty) => false .

rl member(E, N ; NS) => E =:= N >> true .

• Example of execution

search member(N:Nat,0 ; s 0 ; s s 0) ˜>! true .

Solution 1 Solution 2 Solution 3

N:Nat --> 0 N:Nat --> s 0 N:Nat --> s s 0

No more solutions.

• Transformation proved sound and complete in FLP community(for successful derivations to values).


Feature 5: Extra variables

Outline1 Motivation










10 Conclusions


Feature 5: Extra variables

Extra variables

• Extra variables in right hand sides of rules are not problem fornarrowing and are necessary for real constraint solving capabilities.

• Extra variables are inherited from logic programming

• Common example of use in FLP languages

op _++_ : NatList NatList -> [NatList] .

rl nil ++ NL’ => NL’ .

rl (N : NL) ++ NL’ => N : (NL ++ NL’) .

op last : NatList -> [Nat] .

rl last(NL) => NL’ ++ (E : nil) =:= NL >> E [nonexec] .

• Nonexec attribute necessary because Maude does not allow extravariables. Other notation required for future versions

• Example of execution

search [1] in last(0 : s 0 : s s 0 : nil) ˜>! X:Nat .

Solution 1

X:Nat --> s s 0

No more solutions.


Feature 6: Constraint solving and residuation

Outline1 Motivation










10 Conclusions



Constraint solving

• Constraint solving capabilities quite effective in logic programmingand functional logic programming

• In FLP, constraints defined on sort Success and operator =:=

• Constraints used in conditional part of a rule or as search command

op _+_ : Nat Nat -> [Nat] .

rl 0 + M => M .

rl (s N) + M => s (N + M) .

search [1] (X:Nat + 0) =:= s 0 ˜>* success .

Solution 1

X:Nat --> s 0

No more solutions.

• Huge state space and non-termination problems

• New symbol & for combination of constraints

op _&_ : [Success] [Success] -> [Success] [assoc comm id: success] .

• Symbol & built-in operator in FLP languages with elaboratedsemantics but very simple in Maude



Residuation• Functional logic programming (and logic programming) make use of

suspended constraints to split which part of a constraint generatesall possible instantiations and which part of the constraintsconsumes those instantiations

• The idea to delay or suspend function calls until they are ready fordeterministic evaluation

• Nicely represented in Maude with the distinction of rules andequations: rules for narrowing and equations for rewriting onlyop nat : Nat -> [Success] .

rl nat(0) => success .

rl nat(s N) => nat(N) .


eq 0 + M = M .

eq (s N) + M = s (N + M) .

search [1] nat(X:Nat) & (X:Nat + 0) =:= s 0 ˜>! success .

Solution 1

X:Nat --> s 0

No more solutions.

• Reduced search spaceSantiago Escobar (UPV) Festschrift in Honor of Kokichi Futatsugi (SAS 2014) 42 / 49


User-definable order

• However, in many situations we have to reduce the search space byimposing an order of evaluation among different constraints

• Modern functional logic programming languages (e.g. Curry) providea symbol &> built-in operator

• This is simply done in our case with >>

op nat : Nat -> [Success] .

rl nat(0) => success .

rl nat(s N) => nat(N) .


eq 0 + M = M .

eq (s N) + M = s (N + M) .

search [1] nat(X:Nat) >> (X:Nat + 0) =:= s 0 ˜>! success .

Solution 1

X:Nat --> s 0

No more solutions.

• Very much reduced search space


Missionaries and Cannibals revisited

Outline1 Motivation










10 Conclusions



Missionaries and Cannibals revisitedmod MAC is pr SUCCESS . pr TRIPLIST . pr PSET .

ops taylor helen william : -> Elem [ctor] . ops umugu nzwawe amoc : -> Elem [ctor] .

var L : TripList . var T : Trip . var PS : PSet .

op gen : Elem -> [Success] .

rl gen(taylor) => success . eq gen(taylor) = success .

rl gen(helen) => success . eq gen(helen) = success .

rl gen(william) => success . eq gen(william) = success .

rl gen(umugu) => success . eq gen(umugu) = success .

rl gen(nzwawe) => success . eq gen(nzwawe) = success .

rl gen(amoc) => success . eq gen(amoc) = success .

op m0 : -> [PSet] . op c0 : -> [PSet] .

eq m0 = taylor helen william . eq c0 = umugu nzwawe amoc .

op mset : PSet -> [PSet] . op cset : PSet -> [PSet] .

eq mset(PS) = PS /\ m0 . eq cset(PS) = PS /\ c0 .

op boatok : Trip -> [Success] . op boat : PSet -> Trip [ctor] .

eq boatok(boat(X:Elem)) = gen(X:Elem) .

eq boatok(boat(X1:Elem X2:Elem)) = gen(X1:Elem) >> gen(X2:Elem) >> ((X1:Elem =/= X2:Elem) =:= true) .

ops lb rb : TripList -> [PSet] .

eq lb(nil) = m0 c0 . eq lb(L * boat(PS)) = if (even # L) then (lb(L) - PS) else (lb(L) PS) fi .

eq rb(nil) = empty . eq rb(L * boat(PS)) = if (even # L) then (rb(L) PS) else (rb(L) - PS) fi .

op good : TripList -> [Success] .

eq good(nil) = success .

eq good(L * T)

= boatok(T) >> good(L) >> ( (# cset(lb(L * T)) =< # mset(lb(L * T))

or (# mset(lb(L * T)) == 0))

and

(# cset(rb(L * T)) =< # mset(rb(L * T))

or (# mset(rb(L * T)) == 0)) ) =:= true .

op solve : TripList -> [Success] .

eq solve(L) = good(L) >> (lb(L) == empty) =:= true .

endm



Notes on the Maude-MAC example

• Logic predicates translated into functions solve, good, boatok

• Use of a predicate gen for instantiating missionaries and cannibals.

• Use of rules and equation for gen. No more rules (very reducedsearch space)

• Use of >> in conditions for speeding up evaluation of constraints

• Libraries for lists, for symbol #, for /\, etc.



Evaluation• One of the possible solutions issearch solve(nil * boat(taylor umugu) * boat(taylor) * boat(nzwawe amoc) * boat(umugu) *

boat(william helen) * boat(helen nzwawe) * boat(taylor helen) *

boat(amoc) * boat(umugu amoc) * boat(helen) * boat(helen nzwawe) ) =>! success .

Solution 1

empty substitution

No more solutions.

• The person chosen in the last two steps, e.g. helen, is irrelevant:search solve(nil * boat(taylor umugu) * boat(taylor) * boat(nzwawe amoc) * boat(umugu) *


boat(amoc) * boat(umugu amoc) * boat(E) * boat(E nzwawe) ) ˜>! success .

Solution 1 Solution 2 Solution 3 Solution 4 Solution 5

E:Elem --> amoc E:Elem --> helen E:Elem --> taylor E:Elem --> umugu E:Elem --> william

No more solutions.

• The cannibal chosen in steps 9th and 10th is irrelevant:search solve(nil * boat(taylor umugu) * boat(taylor) * boat(nzwawe amoc) * boat(umugu) *


boat(E1) * boat(umuguE1) * boat(E) * boat(E nzwawe) ) ˜>! success .

Solution 1 Solution 2

E1:Elem --> amoc ; E:Elem --> amoc E1:Elem --> amoc ; E:Elem --> helen


E1:Elem --> amoc ; E:Elem --> taylor E1:Elem --> amoc ; E:Elem --> umugu


E1:Elem --> amoc ; E:Elem --> william E1:Elem --> nzwawe ; E:Elem --> amoc

Solution 7

E1:Elem --> nzwawe ; E:Elem --> umugu

No more solutions.

• However, huge state space for search solve(L) ˜>* success


Conclusions

Outline1 Motivation










10 Conclusions


Conclusions

Conclusions

• How concurrent constraint functional logic programs can be writtenand executed by using the novel infrastructure of narrowing assymbolic reachability in Maude.

• Maude goes beyond standard practices in the functional logic area

• A detailed comparison of features that are available in Curry orMaude is outside of this paper

• A detailed comparison of performance is outside of this paper


Documents

Functional Logic Programming in Maude...Motivation Outline 1 Motivation Why narrowing in Maude Missionaries and Cannibals Our contributions 2 Rewriting logic in a nutshell Narrowing