>>> "Paul" == Paul Eggert <[EMAIL PROTECTED]> writes:
> Bob Rossi <[EMAIL PROTECTED]> 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.
