Page 1 of 1
Parser generator invalid code
Posted: 18 Feb 2015 15:47
by Peter Muraya
Code: Select all
productions
EXPRESSION =
/*
This expression without the cursor tracking generates valid code*/
/*EXPRESSION plus EXPRESSION -> plus(EXPRESSION, EXPRESSION),*/
/*
With the :CURSOR the generated invalid code*/
EXPRESSION plus:CURSOR EXPRESSION -> plus(EXPRESSION, CURSOR, EXPRESSION)
/*
Other arithmetic expressions come here*/
--
int(INTEGER) -> int(INTEGER),
real(REAL) -> real(REAL)
The generated clauses; the invalid part is highlighted.
Code: Select all
clauses
s_expression(LL1,LL0,EXPRESSION):-
s_expression1(LL1,LL0,EXPRESSION).
s_expression1(LL1,LL0,EXPRESSION_):-
s_expression2(LL1,LL2,EXPRESSION),
s_expression3(LL2,LL0,EXPRESSION,EXPRESSION_).
s_expression2([t(int(INTEGER),_)|LL],LL,int(INTEGER)):-!.
s_expression2([t(real(REAL),_)|LL],LL,real(REAL)):-!.
s_expression2(LL,_,_):-syntax_error("Expression2",LL),fail.
s_expression3([t(plus,CURSOR)|LL1],LL0,EXPRESSION,EXPRESSION_):-!,
s_expression2(LL1,LL2,EXPRESSION1),
s_expression3(LL2,LL0,plus(EXPRESSION,CURSOR,EXPRESSION1),EXPRESSION_) ,CURSOR=EXPRESSION,EXPRESSION=CURSOR.
/*
The generator should not produce this additional bit ,CURSOR=EXPRESSION,EXPRESSION=CURSOR. in the previous line*/
s_expression3(LL,LL,EXPRESSION,EXPRESSION).
Posted: 19 Feb 2015 16:04
by Thomas Linder Puls
I am afraid that I do not recall many details of that parser generator. And since Vip 7.5 (Commercial Edition) contains a brand new and much more professional parser generator (used in Visual Prolog compiler) we will not really spend resources on the old parser generator.
See
LALR Parser Generator.
Parser generator invalid code
Posted: 19 Feb 2015 17:10
by Peter Muraya
Thanks Thomas. Now I have 2 compelling reasons to upgrade to VP 7.5: the updated parser generator and the code re-factoring option that I badly need.
Parser generator invalid code
Posted: 21 Feb 2015 10:59
by Peter Muraya
Hi,
I have now upgraded to VP 7.5 and had a brief look at the folder vpiLalrGen. Could you please point me to the documentation, if any, of a vpiGrm file?
Thanks
Posted: 21 Feb 2015 22:11
by Thomas Linder Puls
I am afraid that the only documentation is that in
LALR Parser Generator.
(And the grammar file describing the grammar files themselves (but that is obviously "eats its own tail")).
Parser generator invalid code
Posted: 22 Feb 2015 10:10
by Peter Muraya
Thanks.
I looked at the grammar in expressionGrm and found the following code that uses A,B as parse tree reference names.
Code: Select all
nonterminals
exp : expression.
rules
exp { mkBinOp(Op, A, B) } ==>
exp { A },
[t_cmp] { Op },
exp { B }.
Then I looked the LALR parser documentation and found this similar example but using a and b. Does the case matter?
Code: Select all
exp { mkBinOp(Op, a, b) } ==>
exp { a },
[t_cmp] { Op },
exp { b }.
I am not sure how to handle the cursor -- the very reason I had problems with the old parser generator. I did not get much insights by looking at the grammarDef.vpiGrm -- yes the issue of "the dog trying to eat its own tail".In the old parser it was easy:
Code: Select all
EXP = EXP t_comp:CURSOR EXP -> compare(EXP, CURSOR, EXP)
My intuition tells me that in the new parser it should be coded as:-
Code: Select all
Exp{mkBinOP(Op,A,B, Cursor)} ==>Exp{A}, [t_comp]{Op}, ??{Cursor}, Exp{B}.
But I am not sure what to put in ??
Help.
Posted: 22 Feb 2015 13:13
by Thomas Linder Puls
Casing matters and the mentioned letters should should start with an upper-case (it is fixed now). Everything in braces are Visual Prolog terms (variables and expressions).
In the new parser you only have access to the cursor of an entire rule, which is in the predefined variable Cursor. Cursors consist of an start and an end point and it also contains comments.
I am going to write extend the article with more about cursor and comment handling, and about the use of the [error] symbol for error recovery.
Parser generator invalid code
Posted: 23 Feb 2015 9:43
by Peter Muraya
Thanks. So, if I really wanted a cursor for the [t_comp] token I would need two rules. Correct?
Code: Select all
Exp{mkBinOP(Op,A,B, MyCursor)} ==>Exp{A}, Comp{op(MyCursor, Op)}, Exp{B}.
Comp{op(Cursor, Op)} ==> [t_comp]{Op}.
Posted: 23 Feb 2015 10:21
by Thomas Linder Puls
Yes you will need two rules.
Your grammar rules are however not legal. First of all the nonterminal symbols must start with a lowercase letter. Secondly, you can only write variable names in the bodies of the rules:
Code: Select all
nonterminals
exp : expression.
rules
exp { mkBinOp(Comp, A, B) } ==>
exp { A },
comp {Comp }, % here you can only write a variable
exp { B }.
nonterminals
comp : tuple{cursor Cursor, string Operator}.
rules
comp { tuple(Cursor, Operator) } :-
[t_comp] { Operator }.
Given this the predicate
mkBinOp must be decalared like this:
Code: Select all
predicates
mkBinOp : (tuple{cursor Cursor, string Operator}, expression A, expression B) -> expression A_op_B.
Parser generator invalid code
Posted: 23 Feb 2015 12:05
by Peter Muraya
Many thanks.