bison-patches
[Top][All Lists]
Advanced

[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




reply via email to

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