[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: push parser
From: |
Joel E. Denny |
Subject: |
Re: push parser |
Date: |
Wed, 6 Dec 2006 03:11:04 -0500 (EST) |
On Tue, 5 Dec 2006, Bob Rossi wrote:
> Actually, currently, the user can not access the fields at all. That's
> what I'm trying to say. The user can not index into the struct, because
> the struct is only forward declared in the users translation unit. I
> think it's good to not allow the user access to this structure. However,
> if it's desired and thought wise, it can be done.
Ah, I get it now, thanks. I was thinking of code in the same translation
unit. For example, imagine the user who writes his main routine in the
epilogue.
I'm usually not too concerned about supporting users who mess around in
undocumented parser internals. However, there's another advantage with
your approach: if we have a yypstate_new, users will be forced to think
about memory management, and so they'll hopefully be encouraged to think
about invoking a yypstate_delete. For now, yypstate_delete would simply
call free, but one day (or in some other skeleton) it may need to do more.
In other words, we can evolve without breaking legitimate user code.
By the way, why does yypvarsinit return a void* instead of a struct
yypvars*?
Also, I think Bison should generate:
typedef struct yypvars yypvars;
similar to YYSTYPE and YYLTYPE.
> > > > 4. If %push-parser implies %pure-parser, why not code that logic into
> > > > parse-gram.y? That is:
> > > >
> > > > | "%pure-parser" { pure_parser = true; }
> > > > | "%push-parser" { push_parser = true; pure_parser = true; }
> I see. Well, they don't make sense to put together. However, the
> push-parser and the pure-parser are still very different in the yacc
> skeleton. Sorry if I'm explaining this, and you already know, but at
> least we will be on the same page. The original yacc skeleton has
> several variables in the function yyparse, and 4 variables that are
> global. The pure-parser has all the variables declared in the function
> yyparse. The push-parser declares a lot of the variables in a structure,
> which is passed in and out of yyparse. My point in saying this is to say
> that there is no real correlation between push-parser and pure-parser.
> In fact, if the user sets both options, it should be an error.
I notice you keep saying *the* pure parser rather than *a* pure parser.
I think this is the discrepancy between our views. In my view,
%pure-parser is not a separate kind of parser. Instead, it's one of many
variables defining the parser output by Bison. In theory, it should be
possible to have any of the following combinations:
impure LALR(1) pull C
pure LALR(1) pull C
impure GLR pull C
pure GLR pull C
impure LALR(1) push C
pure LALR(1) push C
impure GLR push C
pure GLR push C
(Now repeat the list for C++.)
However, you have chosen to eliminate the possibility of combining impure
with push. In this view, declaring %pure-parser should be considered
required or redundant but not erroneous. As I recall, Akim argued for the
same view because that's the view he took when he decided C++ parsers
should never be impure.
Now, back to the skeleton where all this matters. Assume your view that a
pure parser and a push parser are two separate kinds of parsers. I see 2
existing places where a b4_pure_or_push_if could abbreviate your code
(both have something to do with b4_declare_parser_variables). Since the
precedent is to have yyerror take a location any time it won't break
backward-compatibility, you'll also need something like b4_pure_or_push_if
in b4_yyerror_args as you suggested here:
http://lists.gnu.org/archive/html/bison-patches/2006-10/msg00058.html
If we're going to have a yypull_parse, there are checks for purity in
computing the yylex prototype that would also need to be changed to check
b4_pure_or_push_if. Finally, I see that your header file is generated
with externs for yylval and yylloc, which shouldn't happen since push
parsers are pure. For glr.c, it looks like all this is going to get even
worse.
Now consider my approach where %push-parser implies %pure-parser. All
those previous places would only need to check b4_pure_if (as most already
do) because all they really are concerned with is purity. I see no place
that you would need a b4_pure_but_not_push_if.
By the way, I just noticed there's something wrong with the m4 in the
header file. You don't generate YYPUSH_MORE and yypvars declarations
unless locations are turned on.
> > > > 7. Shouldn't you remove the yyparse prototype you're currently
> > > > generating
> > > > in push mode?
> > >
> > > The patch I'd like removed completly removes the yyparse function in
> > > push mode. Are you asking about something else?
> >
> > No, it leaves the prototype and a #define. Search the patched push.c for
> > yyparse. The first three occurrences need to be addressed.
>
> I see, you'd like all occurences of yyparse to be completly removed in
> push-parser mode, if we don't add #8. Yes, that makes complete sense.
Actually, especially if we do add #8 since yyparse would be a #define
then.
- Re: push parser, (continued)
- Re: push parser, Bob Rossi, 2006/12/05
- Re: push parser, Bob Rossi, 2006/12/05
- Re: push parser, Joel E. Denny, 2006/12/06
- Re: push parser, Bob Rossi, 2006/12/06
- Re: push parser, Bob Rossi, 2006/12/06
- Re: push parser, Joel E. Denny, 2006/12/06
- Re: push parser, Bob Rossi, 2006/12/06
- Re: push parser, Bob Rossi, 2006/12/07
- Re: push parser, Joel E. Denny, 2006/12/07
- Re: push parser, Bob Rossi, 2006/12/07
- Re: push parser,
Joel E. Denny <=
- Re: push parser, Bob Rossi, 2006/12/15
- Re: push parser, Paul Eggert, 2006/12/15
- Re: push parser, Joel E. Denny, 2006/12/15
- Re: push parser, Paul Eggert, 2006/12/15
- Re: push parser, Joel E. Denny, 2006/12/15
- Message not available
- Message not available
- Re: push parser, Bob Rossi, 2006/12/16
- Re: push parser, Joel E. Denny, 2006/12/16
- Re: push parser, Bob Rossi, 2006/12/16
- Re: push parser, Bob Rossi, 2006/12/17
- Re: push parser, Paul Eggert, 2006/12/16