Hi Ian,
I'm sending this directly to you as I suspect it to be a very specific issue:
I've got a PEG rule of the following form:
Expr =
'x' xt:ExprTail?
| 'this' tt:ExprTail?
| Number nt:ExprTail?
| String st: ExprTail?
ExprTail =
'.' i:Identifier '(' arg:Expr ')' t:ExprTail?
(actually there are a number of other options separated by | but this is the
essence...)
it's now possible to parse things like:
this.id1(this.id2(x)).id3(this.id4(12))
The very peculiar problem I'm experiencing here, is that sometimes, when it is
parsing '12' (using the 'Number...' option of the Expr rule), it claims
the 'nt' variable contains a value, more specifically the value 'x'.
It doesn't happen in very simple cases, but as soon as, in the same parsing
run, the Expr rule is invoked multiple times, likelihood increases.
Very strangely, I can sometimes make the problem go away in particular cases
by just rearranging the order of the | clauses. This would make sense if I
would rearrange two clauses which actually occur, but that needs not be the
case. For the example above, the problem went away if I rearranged the Expr
rule like this:
Expr =
'x' xt:ExprTail?
| 'this' tt:ExprTail?
| String st: ExprTail?
| Number nt:ExprTail?
So I moved the 'String' option up. The weird thing is that this helps even
though there are no strings at all in the example! (strings are between "").
I looked at the generated .peg.k file, and noticed that variables such as 'nt'
are introduced as being "active". Could this have something to do with this?
Because I get the impression that the value in 'nt' is NOT the result of
parsing '12' (indeed, there simply is no ExprTail following...), but rather
that an 'old' value (indeed, 'x' was parsed before '12') was still present in
the memory location associated with 'nt'.
Do you have any idea at all what might be causing this odd behaviour? Did I
maybe do something illegal in the rule definition? (You may notice that this
*Tail pattern was introduced to eliminate left recursion) Is it possible that
these "active" variables aren't reset properly in cases where a rule is
invoked multiple times during the same run? Is it something completely
different? :)
Thanks,
Hans
--
A liberal is a person whose interests aren't at stake at the moment
-- Willis Player
Hans Schippers
Research Assistant of the Research Foundation - Flanders (FWO - Vlaanderen)
http://www.win.ua.ac.be/~hschipp/
Formal Techniques in Software Engineering (FoTS)
University of Antwerp
Middelheimlaan 1
2020 Antwerpen - Belgium
Phone: +32 3 265 38 71
Fax: +32 3 265 37 77
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
