help-bison
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Passing filled AST to yyparse() caller after successful parse


From: Jeannot Langlois
Subject: Re: Passing filled AST to yyparse() caller after successful parse
Date: Sun, 08 May 2005 14:58:28 -0400
User-agent: Mozilla Thunderbird 0.8 (X11/20040913)



Jeannot Langlois wrote:
In a reentrant GLR parser, how must the yyparse() caller proceed to access the filled AST after a successful parse?  I was expecting yyparse() to return a pointer (whose type could be custom-defined by the user just like the yylex() and yyparse() input parameters) to the properly-filled AST, but it seems that this is not the case and the yyparse() return value is only used to return a parse status code.

Any ideas or documentation pointers about that?
I am not sure the %glr parser currently works in pure mode. Let's cc Paul Hilfinger, who wrote it, to see if he can let us know.
-- Hans Aberg

Hi Hans (and Hi all), Just a few minutes after I posted the question to the mailing list, I found what I was looking for. It works. Apparently, when using a reentrant GLR parser, I need to define an (additional) %parse-param { ... } so I can pass the resulting AST pointer to yyparse(),

I am aware of this one, but I was not sure if it resulted in a pure parser. There was a discussion here or in Bug-Bison on some problems with %glr, but I do not remember exactly it was. -- Error recovery perhaps.
Hi again Hans (and others),


Ok. 

(BTW I am using Bison 2.0...).


I am pretty sure there should not be any problems with this and that the resulting parser would still be pure:  I just ran a quick search through my parser's generated .c file and all references made to the %parse-params I have defined are made in a proper way: The only places where my %parse-params get modified are in the user actions and the yyparse() caller (as I would expect them too since I wrote that code); in all other occurrences of the %parse-params, they are only passed to various functions generated by bison (including yyFail() and yyrecoverSyntaxError() and are never globally accessed/written to in any way. 

That said, I can't see how this wouldn't work properly in a multithreaded application that would call yyparse() concurrently with different %parse-params.


CC'ing Paul Hilfilger on this.

Thanks for your quick answer :).


--
Jeannot Langlois - Signature Jeannot Langlois
B. Sc.  Computer Science / B. Sc.  Informatique
Software Developer / Programmeur-Analyste
System/Network Administrator / Administrateur Système/Réseau

LINUX_LOGO




reply via email to

[Prev in Thread] Current Thread [Next in Thread]