Dong Tiger wrote:
Look at the following expression( c-like syntax):
1 - 2 * (TYPE_OR_VAR) - 1
The real token type of TYPE_OR_VAR is unknown. The expression could be
parsed as the following two options:
1. TYPE_OR_VAR is a typename. Then "(TYPE_OR_VAR)-1" is a cast expression.
And the exp
Hans Aberg wrote:
You should have gotten an ambiguous grammar. Then Bison still produces a
runnable parser by choosing: in the case of reduce/reduce conflicts,
shift over reduce, and in the case of reduce/reduce conflicts, the first
occurring reduce in the .y grammar.
Since we are talking abo
Hans Aberg wrote:
On 7 Mar 2006, at 18:42, Sylvain Schmitz wrote:
Too many states means less chances of merging concurrent stacks. One
could also point out that less inadequate states means less branching,
but the number of inadequate states avoided when using LR(1) instead of
LALR(1) is not
Hans Aberg wrote:
On 7 Mar 2006, at 10:39, Sylvain Schmitz wrote:
About LR(1), I recently found out menhir
<http://pauillac.inria.fr/~fpottier/menhir/menhir.html.en>, which
implements LR(1) using Pager's method: even today, the direct generation
of a full-blown LR(1) parser is to
Hans Aberg wrote:
As for the optimizations mentioned, I suspect they are old; they
probably seemed important in older times, when computing time and space
was very expensive.
It's true they are getting old, and bison is already pretty fast.
Except in some specific cases, I also doubt anyone
Frans Englich wrote:
Sometimes I write grammar constructs like this:
StringLiteral: STRING_LITERAL
and use StringLiteral in subsequent rules, instead of STRING_LITERAL directly.
The reason is readability, and to stay consistent with an EBNF specification.
I wonder, does this cause a negative
Krisakorn Rerkrai wrote:
That means I can skip "yyin" and "yyparse" and simply call
"yy_scan_string()". Is that right?
Almost; you won't have to set yyin because yy_scan_string does it for
you. You still have to use yyparse (which in turn calls yylex, which
will use the string buffer set up
Krisakorn Rerkrai wrote:
Is it really required to parse from yyin??
In case I don't want to read my query from a file.
How can I do
parse_this(para1, "SELECT hot_food FROM menu");
When using bison, it's the lexer's job to feed tokens to the parser; so
yyin is really controlled by your lexer.
David Ja wrote:
All I wanted to do was to
take advantage of bison's parser which generates the DFA, which in turn,
allows me to step through the DFA in sequence generating a sample string
that fits the grammar input.
Are you clear with the fact that the DFA generated by bison is not a DFA
fo
Frans Englich wrote:
state 118
72 SequenceType: ItemType .
73 | ItemType . STAR
74 | ItemType . PLUS
75 | ItemType . QUESTION_MARK
PLUS shift, and go to state 134
STAR shift, and go to state 135
QUESTION_MARK shift
jojo wrote:
I want to make a scanner for my microcontroller who is getting
> messages (not longer than 160 chars; example:
> "var1=34.34;var2="test";var3=5"). Those messages are stored in
> a buffer (char buff[160]). The mc should scan and react to this
> messages in doing something and post a m
Paul Eggert wrote:
Sylvain Schmitz <[EMAIL PROTECTED]> writes:
It might have been true when these skeleton first appeared, but I
don't think it is any more, since both commercial and open source
implementations exist now.
OK, let's solve the problem. The first step: could you ple
Paul Hilfinger wrote:
In fact, this issue did get discussed when the GLR skeleton got
introduced, and the language (or lack of it) is, AIR, deliberate on
the part of the lead maintainers at the time. On consideration, I
would prefer that the same terms apply to all skeletons as now apply
to the C
13 matches
Mail list logo
