Hi Mark, the third argument is an (optional) token value (which is of type YYSTYPE -- which corresponds to the Bison %union declaration).
Yours, Alex On 14.08.19 18:10, Mark Bannister wrote: > Hi Alex > > I see my mistake! I read the docs incorrectly and presumed > yypush_parse() was taking a function pointer. Excellent, I think this > is just what I want. > > So in the example: > > status = yypush_parse(ps, yylex(), NULL); > > I take it that the first argument is yypstate* and the second argument > is the next token. What is the third argument? bison.info only appears > to document a single-argument version (the impure version). > > Thanks, > Mark > > Sent from Yahoo Mail on Android > <https://go.onelink.me/107872968?pid=InProduct&c=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers&af_wl=ym&af_sub1=Internal&af_sub2=Global_YGrowth&af_sub3=EmailSignature> > > On Wed, 14 Aug 2019 at 16:44, Martin Alexander Neumann > <a...@maneumann.net> wrote: > Hi Mark, > > ah, yypush_parse does not take a pointer to yylex as second parameter, > the second parameter is the actual token (you have scanned somewhere > else). > > Yours, > Alex > On 14.08.19 17:28, Mark Bannister wrote: > > Hi Alex > > > > Thanks for your reply, I had already read up on push parsers before my > > posting. > > > > As you will see from the example on the Push-Decl page, yypush_parse() > > takes a pointer to yylex(), so the push parser will call my lexer in > > order to get tokens. > > > > However, if in effect my lexer has the control loop, it already > has the > > tokens so I would need a way of calling yypush_parse() with a > token that > > I already have and not require it to make a separate call to yylex(). > > > > Is that possible? > > > > Best regards > > Mark > > > > Sent from Yahoo Mail on Android > > > > <https://go.onelink.me/107872968?pid=InProduct&c=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers_wl=ym_sub1=Internal_sub2=Global_YGrowth_sub3=EmailSignature > > <https://go.onelink.me/107872968?pid=InProduct&c=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers&af_wl=ym&af_sub1=Internal&af_sub2=Global_YGrowth&af_sub3=EmailSignature>> > > > > On Wed, 14 Aug 2019 at 16:02, Martin Alexander Neumann > > <a...@maneumann.net <mailto:a...@maneumann.net>> wrote: > > Hi Mark, > > > > please have a look at instructing Bison to generate a push parser > > instead of a pull parser (which is the default): > > > > https://www.gnu.org/software/bison/manual/html_node/Push-Decl.html > > > > Yours, > > Alex > > > > On 14.08.19 09:14, Mark Bannister via help-bison wrote: > > > I am writing a Bison re-entrant push parser with my own lexical > > analyser. However, if my understanding is correct, the only way I > > know to make this work is a bit inefficient. > > > I have a debugger interface that I'm developing that takes one > > line of input at a time. The debugger then decides which language > > module to call based on a simple pattern match. It invokes an > > entry-point in the correct module with the line of input it has > > received. Only one of the language modules will use bison, the > > other interfaces are too simple to need it. Once I am in the > > language module I am scanning for tokens and some simple context. > > For example, it's possible to call out to another language module > > from here too so this loop cannot be implemented in bison as the > > full grammar cannot be defined at this point. Also, the syntax > > structure may be varied depending on the value of a variable, and > > this affects whether or not a complete statement is or is not > > terminated by semicolons, for example. > > > What I would like to do is call my bison parser for each token > > that I collect in the main loop of my language module, and from > > there I can create an AST. So, for example, I would go: > > > Debugger -> Module Loop -> Bison (per token) -> AST > > > This obviously requires a push parser, but the problem I am > facing > > - and the reason for my call for help - is that bison wants to call > > a lexer even though I already have the token I need to push to it. > > So it appears to be back-to-front. The only way I can think of > > right now to solve the problem is to store my token in a structure > > that I pass by reference to bison, which it passes to a lexer > > function that just extracts the details and returns it back to > > bison. I think this should work but it is suboptimal and looks > like > > this: > > > Debugger -> Module Loop -> Bison (per token) -> lexer (return > > token) -> Bison -> AST > > > Is there a better way? > > > Best regardsMark > > > > > > Sent from Yahoo Mail on Android > > > > > _______________________________________________ > > > help-bison@gnu.org <mailto:help-bison@gnu.org> > <mailto:help-bison@gnu.org <mailto:help-bison@gnu.org>> > > > https://lists.gnu.org/mailman/listinfo/help-bison > > > > > > > > _______________________________________________ help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison
