date:20050301

Re: Forcing multiple parse stacks to 'reduce'

2005-03-01 Thread Laurence Finston

> Derek M Jones wrote:
>
> > >>I have written a parser for C that processes
> > >>a single statement or declaration at a time.
> > >>So after each statement/declaration yyparse
> > >>returns.
> > >

I think you might be able to simplify matters by just using
`statement' as your start symbol and calling `yyparse()'
in a loop.  If that doesn't work, it might help to define your start
symbol as follows:

program: statement END

and pass `END' to `yylex()' from the actions for the rules
with `statement' as the left-hand side for immediate return to
`yyparse()'.  In order to do something similar, I pass a parameter to
`yyparse()' which is passed in turn to `yylex()'.  It is of a class type
which contains a data member called `rescan_stack'.  Put in a somewhat
oversimplified way, if it's not empty, it contains one or more tokens, and
`yylex()' immediately pops the top token from the stack and returns it to
`yyparse()'.  You could use another data member of the parameter to
indicate whether you've reached the end of the file.  In my parser, an EOF
never reaches `yyparse()'.

Laurence Finston
http://www.gnu.org/software/3dldf/LDF.html

___
Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison

Re: Forcing multiple parse stacks to 'reduce'

2005-03-01 Thread Derek M Jones

Hans,

>>In the case:
>>
>>typedef x, y;
>>typedef i, j;

I should have given the example as:

typedef x y;
typedef i j;

>>
>>the second typedef token is shifted onto all three stacks and
>>subsequent tokens are processed like a declaration (which they
>>do form part of)!  So I don't get a parse of a single declaration
>>(in fact yyparse eventually reports an ambiguity).

Mystery solved (while cutting down the grammar to provide a
minimum example).

The syntax for function definition (clause 6.9.1) is

function-definition:
declaration-specifiers declarator declaration-list-opt compound-statement

I have changed this to:

function-definition:
declaration-specifiers declarator declaration-list-opt  OPEN_CURL

I suddenly realised that the token sequence:

typedef x y;
typedef i j;
{

is a syntactically valid function definition.

Bison is correct not to perform the reductions I was
expecting.  Until a {, or EOF, is seen it does not it does not
know whether it is dealing with a function definition or a
list of declarations.


derek

--
Derek M Jones   tel: +44 (0) 1252 520 
667
Knowledge Software Ltdmailto:[EMAIL PROTECTED]
Applications Standards Conformance Testing   http://www.knosof.co.uk




___
Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison

Re: Identifying rule responsible for lookahead

2005-03-01 Thread Soumitra Kumar

Henrik,

I understand that grammar is ambiguous.
In case of big grammars, it gets difficult to find out
the rules causing the conflicts.

While creating the lookahead set, if bison can
annotate the rules too, it would be helpful.

So, if I get the following output (rule no after a
lookahead symbol), finding the ambiguous rules is
trivial.

state 10

3 hier_id: hier_id . opt_select YYDOT simple_id
4 opt_select: .  [YYDOT (3), '[' (5)]
^^^  ^^^
5   | . opt_select '[' expr ']'
7 expr: hier_id .  [YYDOT (9), ']' (5)]

YYDOT reduce using rule 4 (opt_select)
YYDOT [reduce using rule 7 (expr)]

I was wondering if there is a way to get this
information out of bison.

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


___
Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison

Re: Identifying rule responsible for lookahead

2005-03-01 Thread Henrik Sorensen

On Tuesday 01 March 2005 19.02, Soumitra Kumar wrote:
> Henrik,
> So, if I get the following output (rule no after a
> lookahead symbol), finding the ambiguous rules is
> trivial.
well, in the output file you can search for all the states that have a goto 
your state 10.


___
Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison

Re: Forcing multiple parse stacks to 'reduce'

2005-03-01 Thread Hans Aberg

At 19:24 + 2005/02/28, Derek M Jones wrote:
>>>I have written a parser for C that processes
>>>a single statement or declaration at a time.
>>>So after each statement/declaration yyparse
>>>returns.
>>
>>Bison is clearly not built to handle such applications. The normal thing is
>>to handle the whole language in one go. (How do you handle environments,
>>like "{...}" statement-by-statement?)
>
>I don't see why not.  Bison is built to handle grammars.
>My grammar does not support sequences of  statements
>or declarations.  The whole language, in my case, consists of
>one statement or one declaration (which includes the
>header of a function definition).  Characters such as { }
>are not part of the grammar (they are handled by a higher
>level routine).

You are clearly not parsing the full C language then, but some subsets. It
is hard to for me to judge, as I do not know what you are doing.

>My aim is to parse the visible source (i.e., preprocessing
>directives are ignored).  Error recovery is better if
>statements/declarations are parsed individually.

LALR(1) usually provides very basic error recovery, as the states LR(1) are
merged together in a way that when an error token is detected, reductions
may become performed before the error is reported. So LR(1) might be better,
but Bison does not support that yet.

>'Errors'
>might be caused by conditional preprocessor directives
>that select how a statement, for instance, should be processed.

C in reality has two languages, a preprocessor language, that produces a
single stream as output. Then that stream is parsed by the actual C
compiler. If you want to get inputs on how to sync that for error reoprting,
you check out te GNU GCC compiler.

>Single statement/declaration at a time localises syntax errors.

But if that is your only motivation, it does not seem mecessary to actually
abort the compilation process, to read one statement at a time.

>>You might try to rewrite your input grammar so that when the ";" of a
>>typedef is encountered, it reduces.
>
>My question is how do I do that?  My grammar is copied
>straight from annex A of the C Standard (plus six or so %dprecs
>and two changes from right recursion to left recursion).

See my other reply. I have a vague memory that people have better ways to
use a LALR(1) grammar with C. Check the newsgroup comp.copmilers and its
FAQ, published there monthly. The original grammar fomr the standrad is
probaly unsuitable for direct LALR(1) implementation.

>I am guessing that some form of lazy evaluation is being used
>internally by Bison.

No.

>After all, in most cases an end-of-file
>indicator is used to force reductions.

This is just a consequence of how the LALR(1) algorithm works. See for
example the AHO et all "Compilers...) ("Dragon") book. For a given input
grammar, one creates an new "augmented" grammar with an endmarker. Provides
push-down automaton is created from that. One is thus parsing a sentence
with a given endmarker, which must be provided by the lexer.

  Hans Aberg

___
Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison

Re: Forcing multiple parse stacks to 'reduce'

2005-03-01 Thread Hans Aberg

At 15:38 + 2005/03/01, Derek M Jones wrote:
>I suddenly realised that the token sequence:
>
>typedef x y;
>typedef i j;
>{
>
>is a syntactically valid function definition.

So it seems, but I have not been able to figure out which function. :-) The
problem is that C has some grammar difficulties.

>Bison is correct not to perform the reductions I was
>expecting.  Until a {, or EOF, is seen it does not it does not
>know whether it is dealing with a function definition or a
>list of declarations.

I have some vague memory that somebody found (fairly late, in the 90'ies) a
grammar transformation to make C becoming LALR(1) (modulo the usual context
tweaks for "typedef", etc.) Then you would not need using the %glr option.
You might check the newsgroup comp.compilers and its FAQ, published there
monthly.

  Hans Aberg

___
Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison

Re: Identifying rule responsible for lookahead

2005-03-01 Thread Hans Aberg

At 12:46 -0800 2005/02/28, Soumitra Kumar wrote:
>Following is a sample grammar. There is one r/r
>conflict.
>
>% cat test.y
>%token YYID YYDOT
>%%
>identifier : hier_id
>;
>hier_id : simple_id
>| hier_id opt_select YYDOT simple_id
>;
>opt_select :
>| opt_select '[' expr ']'
>;
>
>simple_id : YYID ;
>expr : hier_id
>| function_call
>;
>function_call : expr YYDOT YYID
>;
>% bison -r all -v test.y -g
>test.y: conflicts: 1 reduce/reduce
>
>>From test.output:
>state 10
>
>3 hier_id: hier_id . opt_select YYDOT simple_id
>4 opt_select: .  [YYDOT, '[']
>5   | . opt_select '[' expr ']'
>7 expr: hier_id .  [YYDOT, ']']
>
>YYDOT reduce using rule 4 (opt_select)
>YYDOT [reduce using rule 7 (expr)]
>
>YYDOT is in the lookahead set of rule 7 (expr:
>hier_id) because of rule 9 (function_call: expr YYDOT
>YYID).
>
>If nonterminal expr is used is many rules, it gets
>difficult to find out which usage is causing problem.
>
>Basically I want to annotate the rules responsible for
>a lookahead token as follows.
>
>state 10
>
>3 hier_id: hier_id . opt_select YYDOT simple_id
>4 opt_select: .  [YYDOT (3), '[' (5)]
>5   | . opt_select '[' expr ']'
>7 expr: hier_id .  [YYDOT (9), ']' (5)]
>
>YYDOT reduce using rule 4 (opt_select)
>YYDOT [reduce using rule 7 (expr)]
>
>I was wondering if there is a way to get this
>information out of bison.

The problem is how to extract the information from the LALR(1) algorithm, if
possible. Do you have any suggestion? (I may think a bit more on the
question.)

It is otherwise not a help-bison issue, but a "featuritis" issue, which
normally should be posted in the bug-bison list.

  Hans Aberg




___
Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison

$BAG?ML<

2005-03-01 Thread $B%d%oH)H~F}$J=w$N;R(B


ß[éÜª¶ñM-TOWN(^O^)/¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦

[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL 
PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL 
PROTECTED]@[EMAIL PROTECTED]

[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@

   EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE

[EMAIL PROTECTED]://99net.candyhos.com/?v71qupe78e

¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬

[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]

[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL 
PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL 
PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]

[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL 
PROTECTED]@

æXÅ©©¯éÂ¤¢üet³ñâVbvXõ³ñc

iÍ»ñÈÞBàdªIíêÎ¶Å¢ëñÈçðÌ¼©¹éô

»ñÈÞBÌzlðð¦½æâ[r[ÚII(Þ)

 

[EMAIL PROTECTED]://99net.candyhos.com/?v71qupe78e

[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL 
PROTECTED]

y»ðüet`jh¿áñÌêzªªªªªªªªªªªª

[EMAIL PROTECTED]@[EMAIL PROTECTED]@ «

±ÌÜ¦Uíê¿áÁÄ¥c¨ðÌ¨¢à ÁÄ©»ÌÜÜzeÅ«

Gb`µ¿áÁ½ô(*^O^*)[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL 
PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL 
PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@   «

ªªªªªªªªªªªªªªªªªªªªªªªªª®

  `**`**`**`**`*

[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED] ªªªªªªªªª

[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]

[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL 
PROTECTED]@[EMAIL PROTECTED]@«

[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL 
PROTECTED]

  [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL 
PROTECTED]@¯ªªªªªªªªªªªªªªªªªªªªªªª®

 

  http://99net.candyhos.com/?v71qupe78e

[EMAIL PROTECTED]@

 >>>[EMAIL PROTECTED]@

[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL 
PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL 
PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL 
PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@

[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL 
PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL 
PROTECTED]@

 

  
yflIoÅOüzEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE

[EMAIL PROTECTED]@©çêé±ÆªåD«ÈÌq½¿ªFXÈêÅ

[EMAIL 
PROTECTED]@å_k[hðâIôRrjAwÌz[AÔÌAéÌöAetc...

[EMAIL PROTECTED]@£ÍIÈJ_ðÉµ°àÈAs[·élqÉhLhLô

 

[EMAIL PROTECTED]

[EMAIL PROTECTED]@åD]ÌuZÔOÎ

[EMAIL PROTECTED]@¡ñÍÖÆÖ¼»ê¼êÌuZVbvÅA

[EMAIL PROTECTED]@ºðèÉ½flÌÌqÆðÂ¨nBèµ¿á¢Üµ½

[EMAIL PROTECTED]@»ÌênIðûß½usqðÊ^Æ¤ÉåöJI

 

  http://99net.candyhos.com/?v71qupe78e

¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬ ¬¬

***************

ß[éÜª¶ñM-TOWN(^O^)/¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦

 

   EÇÍA[}KWêåÌzMX^hÆÈÁÄ¨èÜ·B

  EÇæèzM³êéîñÌÇÉÂ¢ÄÍsÒÉË¶µÄ¨èÜ·ÌÅA

  [EMAIL PROTECTED]

  EÇÍ²ÐîæÌTCgÉ¨¯é¢©Èéguâ¹QÉÎµÄà

êØÌÓCð¢©ËÜ·B

  EfÚîñÉÖµÄÌ²¿âÉÍ¶Ä¨èÜ¹ñÌÅ\ß²¹³º³¢B

  E[}KWÉfÚ³ê½LÌêÜ½ÍSð

ÂÈ]Ú·é±ÆðÖ~vµÜ·B

  EwÇðð²ó]ÌûÍA¨èÅ·ªºLÌAhXæèOCµA

²©gÅ¨è±«º³¢B

@

[EMAIL PROTECTED] http://mean.m-blue.org/m-town/

***************

***************


___
Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison

Re: Forcing multiple parse stacks to 'reduce'

Re: Forcing multiple parse stacks to 'reduce'

Re: Identifying rule responsible for lookahead

Re: Identifying rule responsible for lookahead

Re: Forcing multiple parse stacks to 'reduce'

Re: Forcing multiple parse stacks to 'reduce'

Re: Identifying rule responsible for lookahead

$BAG?ML<

8 matches

Site Navigation

Mail list logo

Footer information