Can somebody see what I am doing wrong.... I am using the for all quantifier to create this two lines :
(assert(forall((t Task)) (not (mustPrecede t t))))
(assert(forall((t1 Task)(t2 Task)(t3 Task)) (implies (and (mustPrecede t1 t2)(mustPrecede t2 t3)) (mustPrecede t1 t3))))
this is the code..
Sort User = ctx.mkUninterpretedSort("User");
Sort Task = ctx.mkUninterpretedSort("Task");
//function declaration
FuncDecl assignUser = ctx.mkFuncDecl("assignUser", Task, User);
FuncDecl TaskUser = ctx.mkFuncDecl("TaskUser", new Sort[] { Task, User }, ctx.mkBoolSort());
FuncDecl mustPrecede = ctx.mkFuncDecl("mustPrecede", new Sort[]{Task,Task}, ctx.mkBoolSort());
//task for using in quatifiers
Expr task = ctx.mkConst("t",Task);
Expr user = ctx.mkConst("u",User);
// creating (assert(forall((t Task)) (not (mustPrecede t t))))
//just one task is needed
Sort[] Tasks = new Sort[1];
Tasks[0] = Task;
//setting the name for the task
Symbol[] namess = new Symbol[1];
namess[0] = ctx.mkSymbol("t");
//Creating a map between mustPrecede and its two parameters
Expr mtt = ctx.mkApp(mustPrecede, task,task);
//acreating not
Expr body = ctx.mkNot((BoolExpr)mtt);
Expr mustPrecedett = ctx.mkForall(Tasks, namess, body, 1, null, null,
ctx.mkSymbol("Q1"), ctx.mkSymbol("skid1"));
System.out.println("Quantifier mustPrecedett: " + mustPrecedett.toString());
//creating (assert(forall((t1 Task)(t2 Task)(t3 Task)) (implies (and (mustPrecede t1 t2)(mustPrecede t2 t3)) (mustPrecede t1 t3))))
//tree taks will be neede
Sort[] tTask = new Sort[3];
tTask[0] =Task;
tTask[1] =Task;
tTask[2] =Task;
//setting the names for the tasks
Symbol[] Tnames = new Symbol[3];
Tnames[0] = ctx.mkSymbol("t1");
Tnames[1] = ctx.mkSymbol("t2");
Tnames[2] = ctx.mkSymbol("t3");
//creating tree diferent tasks for the relations
Expr t1 = ctx.mkConst("t1",Task);
Expr t2 = ctx.mkConst("t2",Task);
Expr t3 = ctx.mkConst("t3",Task);
//creating mappins
Expr mt1t2 = ctx.mkApp(mustPrecede, t1,t2);
Expr mt2t3 = ctx.mkApp(mustPrecede, t2,t3);
Expr mt1t3 = ctx.mkApp(mustPrecede, t1,t3);
//Creating the relation between them
Expr tbody2= ctx.mkImplies(ctx.mkAnd((BoolExpr)mt1t2,(BoolExpr) mt2t3), (BoolExpr) mt1t3);
//building quatifier
Expr tra = ctx.mkForall(tTask, Tnames, tbody2, 1, null, null,ctx.mkSymbol("Q1"), ctx.mkSymbol("skid1"));
Then I am adding both to the solver as follows:
// creating (assert(forall((t Task)) (not (mustPrecede t t))))
solver.add(ctx.mkForall(Tasks, namess, body, 1, null, null,ctx.mkSymbol("Q1"), ctx.mkSymbol("skid1")));
//creating (assert(forall((t1 Task)(t2 Task)(t3 Task)) (implies (and (mustPrecede t1 t2)(mustPrecede t2 t3)) (mustPrecede t1 t3))))
solver.add(ctx.mkForall(tTask, Tnames, tbody2, 1, null, null,ctx.mkSymbol("Q1"), ctx.mkSymbol("skid1")));
but when asserting
//T2 ; T4 ;(; T12 ; T13 ;AND ; T14 ; T15;) ; T10; T11
Expr T2 = ctx.mkConst("t2", Task);
Expr T3 = ctx.mkConst("t3", Task);
Expr mt = ctx.mkApp(mustPrecede, T2,T3);
Expr mts = ctx.mkApp(mustPrecede, T3,T2);
solver.add(ctx.mkAnd((BoolExpr)mt,(BoolExpr)mts));
The sat solver is reporting SAT.. but this si not possible since mustePrecede is irreflexive according to my previous definitions with quantifiers.. Can somebody see what I am missing or why the sat solver is not considering the "constraints" I added with the foralls??
There are two ways to construct quantified expressions in Z3, one is by using named constants, the other is by de-Brujin indexed variables. The code posted here mixes these two and thus creates expressions that look right, when they aren't.
The following parts:
Sort[] tTask = ...
Symbol[] Tnames = ...
...
Expr t1 = ctx.mkConst("t1",Task);
...
Expr mt1t2 = ctx.mkApp(mustPrecede, t1,t2);
...
Expr tra = ctx.mkForall(tTask, Tnames, ...
construct the body of the quantifier from constants ("t1" etc), but the call to ctx.mkForall requires de-Brujin indexed variables (the indexes are implicit and tTask and tnames assigns names and sorts to them). For this to work, the body needs to be constructed using indexed variables, which are generated by calls to ctx.mkBound(...).
Conversely, if constant expressions are preferred, the quantifier could be constructed by a call to ctx.mkForall(Expr[] boundConstants, ... where the first argument is an array of constant expressions like new Expr[] { t1, t2, t3 }.
The best way to see why the code doesn't work is when the symbols in Tnames are assigned different names. It is then plain to see from in output that there is a mismatch between those variables. For example, changing the code to
....
Expr t1 = ctx.mkConst("x",Task);
Expr t2 = ctx.mkConst("y",Task);
Expr t3 = ctx.mkConst("z",Task);
....
changes the first quantifier to
(forall ((x Task) (y Task) (z Task)) (not (mustPrecede t t)))
Related
I'm currently working on a parser for a simple programming language written in Haskell. I ran into a problem when I tried to allow for binary operators with differing associativities and precedences. Normally this wouldn't be an issue, but since my language allows users to define their own operators, the precedence of operators isn't known by the compiler until the program has already been parsed.
Here are some of the data types I've defined so far:
data Expr
= Var String
| Op String Expr Expr
| ..
data Assoc
= LeftAssoc
| RightAssoc
| NonAssoc
type OpTable =
Map.Map String (Assoc, Int)
At the moment, the compiler parses all operators as if they were right-associative with equal precedence. So if I give it an expression like a + b * c < d the result will be Op "+" (Var "a") (Op "*" (Var "b") (Op "<" (Var "c") (Var "d"))).
I'm trying to write a function called fixExpr which takes an OpTable and an Expr and rearranges the Expr based on the associativities and precedences listed in the OpTable. For example:
operators :: OpTable
operators =
Map.fromList
[ ("<", (NonAssoc, 4))
, ("+", (LeftAssoc, 6))
, ("*", (LeftAssoc, 7))
]
expr :: Expr
expr = Op "+" (Var "a") (Op "*" (Var "b") (Op "<" (Var "c") (Var "d")))
fixExpr operators expr should evaluate to Op "<" (Op "+" (Var "a") (Op "*" (Var "b") (Var "c"))) (Var "d").
How do I define the fixExpr function? I've tried multiple solutions and none of them have worked.
An expression e may be an atomic term n (e.g. a variable or literal), a parenthesised expression, or an application of an infix operator ○.
e ⩴ n | (e) | e1 ○ e2
We need the parentheses to know whether the user entered a * b + c, which we happen to associate as a * (b + c) and need to reassociate as (a * b) + c, or if they entered a * (b + c) literally, which should not be reassociated. Therefore I’ll make a small change to the data type:
data Expr
= Var String
| Group Expr
| Op String Expr Expr
| …
Then the method is simple:
The rebracketing of an expression ⟦e⟧ applies recursively to all its subexpressions.
⟦n⟧ = n
⟦(e)⟧ = (⟦e⟧)
⟦e1 ○ e2⟧ = ⦅⟦e1⟧ ○ ⟦e2⟧⦆
A single reassociation step ⦅e⦆ removes redundant parentheses on the right, and reassociates nested operator applications leftward in two cases: if the left operator has higher precedence, or if the two operators have equal precedence, and are both left-associative. It leaves nested infix applications alone, that is, associating rightward, in the opposite cases: if the right operator has higher precedence, or the operators have equal precedence and right associativity. If the associativities are mismatched, then the result is undefined.
⦅e ○ n⦆ = e ○ n
⦅e1 ○ (e2)⦆ = ⦅e1 ○ e2⦆
⦅e1 ○ (e2 ● e3)⦆ =
⦅e1 ○ e2⦆ ● e3, if:
a. P(○) > P(●); or
b. P(○) = P(●) and A(○) = A(●) = L
e1 ○ (e2 ● e3), if:
a. P(○) < P(●); or
b. P(○) = P(●) and A(○) = A(●) = R
undefined otherwise
NB.: P(o) and A(o) are respectively the precedence and associativity (L or R) of operator o.
This can be translated fairly literally to Haskell:
fixExpr operators = reassoc
where
-- 1.1
reassoc e#Var{} = e
-- 1.2
reassoc (Group e) = Group (reassoc e)
-- 1.3
reassoc (Op o e1 e2) = reassoc' o (reassoc e1) (reassoc e2)
-- 2.1
reassoc' o e1 e2#Var{} = Op o e1 e2
-- 2.2
reassoc' o e1 (Group e2) = reassoc' o e1 e2
-- 2.3
reassoc' o1 e1 r#(Op o2 e2 e3) = case compare prec1 prec2 of
-- 2.3.1a
GT -> assocLeft
-- 2.3.2a
LT -> assocRight
EQ -> case (assoc1, assoc2) of
-- 2.3.1b
(LeftAssoc, LeftAssoc) -> assocLeft
-- 2.3.2b
(RightAssoc, RightAssoc) -> assocRight
-- 2.3.3
_ -> error $ concat
[ "cannot mix ‘", o1
, "’ ("
, show assoc1
, " "
, show prec1
, ") and ‘"
, o2
, "’ ("
, show assoc2
, " "
, show prec2
, ") in the same infix expression"
]
where
(assoc1, prec1) = opInfo o1
(assoc2, prec2) = opInfo o2
assocLeft = Op o2 (Group (reassoc' o1 e1 e2)) e3
assocRight = Op o1 e1 r
opInfo op = fromMaybe (notFound op) (Map.lookup op operators)
notFound op = error $ concat
[ "no precedence/associativity defined for ‘"
, op
, "’"
]
Note the recursive call in assocLeft: by reassociating the operator applications, we may have revealed another association step, as in a chain of left-associative operator applications like a + b + c + d = (((a + b) + c) + d).
I insert Group constructors in the output for illustration, but they can be removed at this point, since they’re only necessary in the input.
This hasn’t been tested very thoroughly at all, but I think the idea is sound, and should accommodate modifications for more complex situations, even if the code leaves something to be desired.
An alternative that I’ve used is to parse expressions as “flat” sequences of operators applied to terms, and then run a separate parsing pass after name resolution, using e.g. Parsec’s operator precedence parser facility, which would handle these details automatically.
I am writing a parser to parse and compute function derivatives in a calculator.
I got a problem with implementing product and quotient rules :
for a product the derivation formula is (u*v)' = u'v+uv', thus I need the value of u and u' in the final output. And with the parser I currently have, whenever comes the need to write u, it has already been replaced by u' and I quite don't know how to save its value, nor if it's even
possible...
Here's the parser :
%token <string> VAR FUNCTION CONST
%token LEFT_B RIGHT_B PLUS MINUS TIMES DIV
%token DERIV
%token EOL
%start<string> main
%%
main:
t = toDeriv; EOL {t}
;
toDeriv:
DERIV; LEFT_B; e = expr; RIGHT_B {e}
;
expr:
u = expr; PLUS v = hat_funct {u^"+"^v}
| u = expr; MINUS; v = hat_funct {u^"-"^v}
| u = hat_funct {u}
;
hat_funct:
u = hat_funct TIMES v = funct {Printf.sprintf "%s * %s + %s * %s" u (A way to save v) v (A way to save u)}
| u = hat_funct DIV v = funct {Printf.sprintf "(%s * %s - %s * %s)/%s^2" u (A way to save v) (A way to save u) v (A way to save v)}
| u = funct {u}
;
funct:
f = func; LEFT_B; c = content; RIGHT_B {Derivatives.deriv_func f c}
;
content:
e = expr {e}
| x = VAR {x}
| k = CONST {k}
func:
f = FUNCTION {f}
| k = CONST {k}
;
P.S : I know it might not be the greatest grammar definition at all, it's still a work in progress
Answering directly your question, yes you can maintain the state of what is being already processed. But that is not how things are done. The idiomatic solution is to write a parser that parses the input language into the abstract syntax tree and then write a solver that will take this tree as input and computes it. You shouldn't do anything in the parser, this is a simple automaton which shall not have any side-effects.
To keep it less abstract, what you want from the parser is the function string -> expr, where expr type is defined something like
type expr =
| Var of string
| Const of string
| Binop of binop * expr * expr
and binop = Add | Mul | Sub | Div
I have a left recursive grammar. My AST looks something like:
...
and Expr = BinaryExpr of BinaryExpr
and BinaryExpr = Expr * BinaryOperator * Expr
and BinaryOperator = Plus
...
I was planning on using the operator precedence parser for this, for example:
let exprOpp = new OperatorPrecedenceParser<Expr,unit,unit>()
let pBinaryExpr = exprOpp.ExpressionParser
exprOpp.TermParser <- pExpr
let consBinExpr op x y = (x, op, y) |> BinaryExpr
exprOpp.AddOperator(InfixOperator("+", ws, 1, Associativity.Left, (consBinExpr Plus)))
where pExpr is a parser for Expr.
The left recursion causes a stack overflow. I was wondering whether there was a particular FParsec-way of dealing with this while still using the OperatorPrecedenceParser?
Thanks!
EDIT:
The issue may be coming from the fact that pExpr forwards all calls to another parser pExprRef.
let pExpr, pExprRef = createParserForwardedToRef()
and after the operator precedence parser, the reference is defined:
do pExprRef :=
choice [pBinaryExpr, <other-parsers...>];
I have a parser implemented with monadic links, something like that:
let rec p1 = parse {}
and p2 = parse {}
and p3 = parse {}
and p = p1 <|> p2 <|> p3
and document = spaces >>? many p .>>? spaces
I would like to implement an arithmetic expression parser that takes as term p:
let opParser = new OperatorPrecedenceParser<_, _, _> ()
// Adding operators
let term = p
opParser.TermParser <- spaces >>? term .>>? spaces
Except that I would like analyzers who use p to be able to use arithmetic expressions as well. So I do this:
let opParser = new OperatorPrecedenceParser<_, _, _> ()
// Adding operators
let rec p1 = parse {}
and p2 = parse {}
and p3 = parse {}
and p = p1 <|> p2 <|> p3 <|> (opParser.ExpressionParser)
let term = p
opParser.TermParser <- spaces >>? term .>>? spaces
The problem is that it causes a stack overflow at runtime.
How can we avoid it while respecting the "contract"?
I have a task to write a (toy) parser for a (toy) grammar using OCaml and not sure how to start (and proceed with) this problem.
Here's a sample Awk grammar:
type ('nonterm, 'term) symbol = N of 'nonterm | T of 'term;;
type awksub_nonterminals = Expr | Term | Lvalue | Incrop | Binop | Num;;
let awksub_grammar =
(Expr,
function
| Expr ->
[[N Term; N Binop; N Expr];
[N Term]]
| Term ->
[[N Num];
[N Lvalue];
[N Incrop; N Lvalue];
[N Lvalue; N Incrop];
[T"("; N Expr; T")"]]
| Lvalue ->
[[T"$"; N Expr]]
| Incrop ->
[[T"++"];
[T"--"]]
| Binop ->
[[T"+"];
[T"-"]]
| Num ->
[[T"0"]; [T"1"]; [T"2"]; [T"3"]; [T"4"];
[T"5"]; [T"6"]; [T"7"]; [T"8"]; [T"9"]]);;
And here's some fragments to parse:
let frag1 = ["4"; "+"; "3"];;
let frag2 = ["9"; "+"; "$"; "1"; "+"];;
What I'm looking for is a rulelist that is the result of the parsing a fragment, such as this one for frag1 ["4"; "+"; "3"]:
[(Expr, [N Term; N Binop; N Expr]);
(Term, [N Num]);
(Num, [T "3"]);
(Binop, [T "+"]);
(Expr, [N Term]);
(Term, [N Num]);
(Num, [T "4"])]
The restriction is to not use any OCaml libraries other than List... :/
Here is a rough sketch - straightforwardly descend into the grammar and try each branch in order. Possible optimization : tail recursion for single non-terminal in a branch.
exception Backtrack
let parse l =
let rules = snd awksub_grammar in
let rec descend gram l =
let rec loop = function
| [] -> raise Backtrack
| x::xs -> try attempt x l with Backtrack -> loop xs
in
loop (rules gram)
and attempt branch (path,tokens) =
match branch, tokens with
| T x :: branch' , h::tokens' when h = x ->
attempt branch' ((T x :: path),tokens')
| N n :: branch' , _ ->
let (path',tokens) = descend n ((N n :: path),tokens) in
attempt branch' (path', tokens)
| [], _ -> path,tokens
| _, _ -> raise Backtrack
in
let (path,tail) = descend (fst awksub_grammar) ([],l) in
tail, List.rev path
Ok, so the first think you should do is write a lexical analyser. That's the
function that takes the ‘raw’ input, like ["3"; "-"; "("; "4"; "+"; "2"; ")"],
and splits it into a list of tokens (that is, representations of terminal symbols).
You can define a token to be
type token =
| TokInt of int (* an integer *)
| TokBinOp of binop (* a binary operator *)
| TokOParen (* an opening parenthesis *)
| TokCParen (* a closing parenthesis *)
and binop = Plus | Minus
The type of the lexer function would be string list -> token list and the ouput of
lexer ["3"; "-"; "("; "4"; "+"; "2"; ")"]
would be something like
[ TokInt 3; TokBinOp Minus; TokOParen; TokInt 4;
TBinOp Plus; TokInt 2; TokCParen ]
This will make the job of writing the parser easier, because you won't have to
worry about recognising what is a integer, what is an operator, etc.
This is a first, not too difficult step because the tokens are already separated.
All the lexer has to do is identify them.
When this is done, you can write a more realistic lexical analyser, of type string -> token list, that takes a actual raw input, such as "3-(4+2)" and turns it into a token list.
I'm not sure if you specifically require the derivation tree, or if this is a just a first step in parsing. I'm assuming the latter.
You could start by defining the structure of the resulting abstract syntax tree by defining types. It could be something like this:
type expr =
| Operation of term * binop * term
| Term of term
and term =
| Num of num
| Lvalue of expr
| Incrop of incrop * expression
and incrop = Incr | Decr
and binop = Plus | Minus
and num = int
Then I'd implement a recursive descent parser. Of course it would be much nicer if you could use streams combined with the preprocessor camlp4of...
By the way, there's a small example about arithmetic expressions in the OCaml documentation here.