Re: Proposed interface changes for "parse.error custom"

[Akim Demaille]

Hi Adrian,

> Le 10 mars 2020 à 11:01, Adrian Vogelsgesang <address@hidden> a écrit :
> 
> Hi Akim
> 
>> if drop yysyntax_error_arguments, then we need two yyexpected_tokens 
>> functions
> I am not sure I can follow you completely here. I agree that we might need 
> two yyexpected_tokens (one for the push parser during normal operation and 
> one for the error state). However, I think we will need so even independent 
> of if we drop yysyntax_error_arguments.

Well, not exactly: if yysyntax_error_arguments were to be kept, the details of 
calling yypstate_expected_tokens when you have a yyparse_context_t would be 
taken care of for you.


> To me, your variant
>> res = yypstate_expected_tokens (yycontext_pstate (ctx), arg, argn);
> seems fine.

Hum...  I feel it's a lot of technical details pushed onto the user.  But maybe 
it's ok.

> I would go for that alternative, since this allows the error handler to 
> interact with the complete parse and, e.g., even "inject" tokens from the 
> error handler. I am having something like JavaScript in mind, where a ";" is 
> injected whenever the parser would otherwise hit a parse error. Not sure if 
> the remaining APIs/bison internals would already be up for it, my point is 
> rather:  I can think of use cases, where one would want to have the complete 
> parser available in error handling, so one can fiddle with it. Hence, 
> introducing `yycontext_pstate` makes sense to me.

Yes, there's no question about that: in push parsers, yyparse_context_t _must_ 
embed yypstate.  I was wondering whether we should provide a convenience 
wrapper:

static int
yyexpected_tokens (const yyparse_context_t *yyctx,
                   int yyarg[], int yyargn)
{
  return yypstate_expected_tokens (yyctx->yyps, yyarg, yyargn);
}

so that the user can use either

res = yyexpectd_tokens (ctx, arg, argn);

instead of

res = yypstate_expected_tokens (yycontext_pstate (ctx), arg, argn);


As for playing with yypstate, well, that's a powerful idea!  But probably not 
from yyreport_syntax_error, where the parser is already in a specific case to 
deal with the error.





Ok, we need to have a larger API, thanks for your feedback!

Looking at the push API which offers rather short names (yypstate is the type, 
yypstate_new,  yypstate_expected_token, ...), I'm starting to wonder whether we 
should move from yyparse_context_t to something like yypcontext.  Or 
yypcontext_t and typedef yypstate_t to yypstate.