Re: Parse error (lack thereof) on incomplete loops

[Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx>]

Peter Stephenson wrote on Fri, 05 Oct 2018 13:47 +0000:
> On Fri, 2018-10-05 at 13:26 +0000, Daniel Shahaf wrote:
> > Can we come up with a one-sided parsing rule for syntactically valid cases?
> > That is, a rule that says guarantees that some constructs are syntactically
> > valid, but doesn't necessarily say anything about other constructs.
> 
> That's pretty much what the the parser in practice does.  If you look at
> the code, it's got tests that read...
> 
> - If SHORTLOOPS isn't set panic at this point.
> 
> - Otherwise go on and see if we can get anything sensible out of what
> we did find.
> 
> So for example the while loop code has...
> 
>     } else if (unset(SHORTLOOPS)) {
> 	YYERRORV(oecused);
>     } else
> 	par_save_list1(cmplx);
> 
> The case that brought this up is that we don't check the return value
> from par_save_list1() (actually a macro at the moment).
> 
> For more explicit rules it's a question of decoding the tests above (if
> we got a "do" then blah, else if we got a "{" then etc. etc.).

Thanks, but that's not quite what I meant.

I meant, we should have a documented rule for which constructs are
syntactically valid when SHORT_LOOPS is set.  Then whenever a question
such as "should <this case> raise a parse error?" comes up, we'd answer
that according to the rule we'd decided upon in advance.  This way the
syntax will be predictable.

The rule should not be defined in terms of the implementation, since it needs
to be able to be used to decide whether the change from 5.5 to 5.6 was a bugfix
or a regression.

Cheers,

Daniel