Re: push parser implemenation

[Akim Demaille]

>>> "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.

 > 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.