On 06/28/2012 04:55 PM, Akim Demaille wrote:
Le 28 juin 2012 à 14:51, Timothy Madden a écrit :
On 06/28/2012 10:09 AM, Akim Demaille wrote:
On the other hand, I could not get GLR with C++ yet…
I have it working, but it's based on horrible hacks. And
I really mean horrible. If PHP in itself does not need it,
I would avoid it.
That is what I was afraid of.
So why don't you give a try to what I proposed?
I see the real php parser (from php source code) does not have a %glr
directive, but it does have %expect 3, and I know php has the dangling
elseif/else problem. Can a language with this issue be written in a LALR(1)
grammar ?
Yes, it can, which is obviously the case of php. I
suspect your question is rather "can this conflict be
explicitly solved instead of relying on the shift
precedence in s/r conflicts". Yes again, give a higher
precedence to the else token than the if-then rule.
Or declare "%right if else".
I would try to include my spaces in the lexer tokens, and I have updated
the lexer input for that, but I have some things I should understand
first, like how does that help the grammar ?
My token type is always std::string, no need for that union. I am eager
to see the new variant-based token type you guys are working on, I think
that will really make the C interface "obsolete". :) Can you also
include some common members, not only alternative members, in the
variant ? Sometimes I want to have a member that selects the token type,
and then a union where I select a member from, basted on the previous
token type, like
struct token
{
enum TokenType { int, string }
token_type;
variant
{
int intToken;
str strToken;
}
};
Back to my grammer file, I think I should still read some more
documentation pages about precedence, as I kinda hoped to avoid that
with more grammar rules, that would make precedence unnecessary for
expressions.
Sorry to say the bison documentation is kind of unpleasant to read. A
significant number of the initial chapters never attempt to cover one
single item or aspect of bison completely. So I am never confident on
what little I have already learned from those chapters, until I get to
the reference chapters.
But if a rule like
if (expr)
stmt;
[elseif (expr)
stmt; ]
[elseif (expr)
stmt; ]
[else
stmt; ]
can be made legal LALR(1), than I no longer understand what is wrong
with the explicit spaces all over every one of my grammer rules.
What is wrong with:
primary_expr:
var | literal | ( space expr space ) ;
multiplicative_expr:
primary_expr
|
multiplicative_expr space op space primary_expr;
additive_expr:
multiplicative_expr
|
additive_expr space additive_op space primary_expr;
if_branch:
space if space ( space expr space ) space stmt;
else_branch:
space else space stmt;
They say space in the above case will make the grammar ambiguous because
that space can include an arbitrary number of tokens, not just one. But
than the compound if statement can have an arbitrary number of elseif
brances, which is again an arbitrary number of tokens, and now I hear
that works.
With my entire grammar, attached previously, ignoring those hundreds of
conflicts I get 'syntax error' on the first binary operator in my php
input file ("=". "+", "*", T_INSTANCEOF, ...). The rules for those
operators seem pretty clear to me in the grammar. Trying to get that
diagram with the `dot` tool from graphwiz took over 48h without
completion on an Inter Core 2 Duo, after which I stopped the process.
What can be wrong with my rules about binary operators, they look pretty
clear to me ?
Thank you,
Timothy Madden
_______________________________________________
help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison