[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: push parser implemenation
From: |
Bob Rossi |
Subject: |
Re: push parser implemenation |
Date: |
Thu, 14 Sep 2006 09:44:37 -0400 |
User-agent: |
Mutt/1.5.11 |
On Thu, Sep 14, 2006 at 11:34:14AM +0200, Akim Demaille wrote:
> >>> "Paul" == Paul Eggert <address@hidden> writes:
>
> > Bob Rossi <address@hidden> writes:
> >> This would mean that the user would have to do "%push-parser
> >> %parse-param (void *PVVOID)" in order to get a valid push parser,
> >> instead of just doing %push-parser. I think this would cause a lot
> >> of user confusion.
> >>
> >> Plus, the yyparse function internally uses the parameter PVVOID, in
> >> order to access the push parser.
>
> > Sorry, I don't know the details of the yyparse function, but I'll
> > try to explain my motivation here.
>
> > If there's an opaque type that the user must pass to yyparse no matter
> > what, then you're right, this should be built in: %parse-param should
> > be used only for extra parameters that the user wants to pass to the
> > parser.
>
> I might be the only one confused, but isn't the confusion cause by the
> lack of definition of what yyparse does? I claim that it always
> implements the pull parser (including constructing and destructing the
> struct maintaining its state). I.e., one has to chose between push
> and pull, but one cannot mix the two in a single parse (but a single
> parser can be used in either way).
>
> So there is a second function, yypush_token, which expects a token. I
> don't think this function should be given the extra %parse-param.
> Rather, these extra parse-param should be stored in the
> parser-struct.
Hi Akim,
I think we should discuess the (yyparse, yyparse_token) idea in the other
email I sent out. However, I still need a decision to be made on the
%parse-param issue. Once we decide on how to handle the user interface
to the parser, we can hopefully come to a settlement on this.
> > However, all other things being equal I'd rather that the opaque type
> > were not void *. In C, it's better to make it struct yysomething *,
> > where struct yysomething is an incomplete type. That makes it more
> > likely that type errors will get caught at compile time, since struct
> > yysomething * is compatible only with itself, whereas void * is
> > compatible with lots of invalid pointer types.
>
> Agreed.
This has already been done, thanks for the input.
Thanks,
Bob Rossi
- Re: push parser implemenation, (continued)
- Re: push parser implemenation, Bob Rossi, 2006/09/12
- Re: push parser implemenation, Paul Eggert, 2006/09/12
- Re: push parser implemenation, Bob Rossi, 2006/09/12
- Re: push parser implemenation, Paul Eggert, 2006/09/12
- Re: push parser implemenation, Bob Rossi, 2006/09/12
- Re: push parser implemenation, Akim Demaille, 2006/09/14
- Re: push parser implemenation, Bob Rossi, 2006/09/14
- Re: push parser implemenation, Paul Eggert, 2006/09/14
- Re: push parser implemenation, Akim Demaille, 2006/09/14
- Re: push parser implemenation, Akim Demaille, 2006/09/14
- Re: push parser implemenation,
Bob Rossi <=
- Re: push parser implemenation, Akim Demaille, 2006/09/14
- Re: push parser implemenation, Akim Demaille, 2006/09/14
- Re: push parser implemenation, Paul Eggert, 2006/09/14
- Re: push parser implemenation, Akim Demaille, 2006/09/14
- Re: push parser implemenation, Akim Demaille, 2006/09/14
- Re: push parser implemenation, Bob Rossi, 2006/09/14
Re: push parser implemenation, Bob Rossi, 2006/09/07
Re: push parser implemenation, Bob Rossi, 2006/09/07
Re: push parser implemenation, Akim Demaille, 2006/09/14
Re: push parser implemenation, Akim Demaille, 2006/09/14