Re: RFC: custom error messages

[Christian Schoenebeck]

On Dienstag, 14. Januar 2020 21:24:59 CET Akim Demaille wrote:
> Hi Christian,
> 
> Thanks for your answer!  I definitely need feedback on these matters.
> 
> > Le 14 janv. 2020 à 14:50, Christian Schoenebeck 
<address@hidden> a écrit :
> >> I wouldn't call memory management in yacc.c "easy": lots of efforts
> >> are made to allocate on the call stack, and to avoid malloc.
> > 
> > For such a new API function it would be easier, e.g. because you don't
> > have to take care about breaking existing users' code. So you could e.g.
> > add an optional allocator argument (where NULL would use Bison's default
> > allocation) for this new API function, or a macro that could be redefined
> > by users, etc. So there would be a bunch of options to address this
> > concern.
> 
> I'm looking for answers that apply in all the backends, so I'm trying
> to stay away from macros.  C++ developers also tend to despise them.

Yes, but unfair comparison. With C++ you can avoid many macros by using 
templates and/or lambda expressions, without facing downsides like reduced 
optimization potential by the compiler or increased memory pressure or 
extensive amount of code, unsafety, etc.

> The current state of my draft looks like this:
> 
> /* Put in YYARG at most YYARGN of the expected tokens given
>    the current YYCTX, and return the number of tokens stored
>    in YYARG.
>    If YYARG is null, return the number of expected tokens.  */
> static int
> yyexpected_tokens (const yyparse_context_t *yyctx,
>                    int yyarg[], int yyargn);
> 
> WDYT?  It should satisfy those who are ready to pay for a dynamic
> allocation, and satisfy those who want a bounded one, at compile
> time.  Anyway, it is always bounded by YYNTOKENS.

Well, it would be fine with me, but not sure if it would for everyone. 
Disadvantage might be that user code would always need to allocate
YYNTOKENS * sizeof(int) for calling this function (e.g. embedded devices).

I haven't seen your implementation, but remembering how I implemented it, it 
is probably not just a single table lookup or anything comparable simple 
action as efficient as Theta(1), right? I mean you are probably walking the 
tables, so a function interface taking an index as argument would not be an 
option for runtime efficiency reason, right?

> >> I do not plan to expose an enum for symbol numbers.  What value would
> >> it bring to give name to these numbers?
> > 
> > To make it clear which internal numbers are actually reflecting user's
> > rules/
> Please, do not use "rule" when you mean "nonterminal symbol".  It
> seems to confuse some people.

I knew I'll get that ticking-off. :) "nonterminal symbol" is too long for 
always using it, and most people know the semantic of "rule" in the context of 
grammars. Invent a better, non ambiguous short term as alternative then. ;-)

> >> I fully subscribe to this view, but string literals are definitely not
> >> the way to go.  So a few months ago I realized that what we really need
> >> to do is to merge Joel E. Denny's PhD into Bison
> >> (https://tigerprints.clemson.edu/all_dissertations/519/).
> >> 
> >> _That's_ the real way forward.  That's Bison 4.
> > 
> > So IMO all other issues discussed here so far would be in the shadow of
> > this major new feature anyway.
> 
> Absolutely.  Joel did a wonderful work.  And it's a pity that it
> went unnoticed for so long.
> 
> > Do you plan to "merge" the high level (user visible) aspects of this
> > built-in scanner support feature "as-is", or have you already ideas about
> > adjusting certain high-level aspects (if that's not too early to discuss
> > at all)?
> So far, I don't see things I would change.  I have not had the
> chance to toy with his version of Bison, and there are legal
> matters to settle.  Also, his schedule is very tight.  But Joel
> and I both agree the marging should happen.  It is far too soon
> for the details though.
> 
> That being said, if you have comments on this regard, you're most
> welcome to shoot!

Sure, but I'll wait for you to resolve the legal matters first.

Any chance that this would be released under a more permissive license, e.g. 
GPL>=2?

> > Last question: I noticed you mentioned it was already hard enough to test
> > Bison code right now. Would it make sense to establish some kind of well
> > defined, distributed test case mechanism for upstream projects? I mean in
> > the sense that upstream projects using Bison would write test cases for
> > their own specific use cases of Bison by using a some kind of defined
> > interface for you to automatically grab, compile and execute them?
> 
> That would be very helpful, indeed.  But in a way, that's the point
> of the betas...  It's not automated, but, well, I do count on you
> guys to really give a shot at the betas and report your mileage.
> 
> On this regard Frank's feedback is extremely valuable.  Even when
> his answer is just "runs fine with my stuff": at least I know someone
> else tried, and it gives me _some_ confidence in the release.

The only way to handle QA are automated tests nowadays. That's the only way to 
go. You barely find people testing things manually today in regular release 
cycles, especially when it comes to tools. Among developers you also see the 
trend that more and more are not running their "own" software manually at all; 
they just write tests (which run automated on remotes), or even: are just 
reviewing those submitted by other people.

Likewise you can be sure I'll get my hands on those planned builtin scanner 
features once they are there, but I won't be able test every Bison release 
manually. That's simply not possible.

> If you look at the past, it's clear that QA is insufficient for
> Bison:
> 
> - v2.7.90 v2.7.91 v3.0 v3.0.1 v3.0.2 v3.0.3 v3.0.4 v3.0.5
> - v3.1
> - v3.1.90 v3.1.91 v3.2 v3.2.1 v3.2.1 v3.2.2 v3.2.3 v3.2.4
> - v3.2.90 v3.2.91 v3.3 v3.3.1 v3.3.2
> - v3.3.90 v3.3.91 v3.4 v3.4.1 v3.4.2
> - v3.4.90 v3.4.91 v3.4.92 v3.5
> 
> In spite of the two betas of v3.2, v3.3 and v3.4, bug fix releases
> were needed.  And I have 3.5.1 ready to be released, although there
> were three betas.
> 
> I don't know how to improve this.
> 
> 
> However, when I was referring to the complexity of testing Bison,
> I was thinking about the test suite: I try to always create
> test cases for the regressions we discover, and for the features
> I add.  But it's difficult, and hard to predict which combination
> of features would break.  And it's impossible to try all the possible
> combinations.

Yeah, that's what I assumed and hence my idea about some kind of formal 
interface for automated downstream test cases. That way you would always have 
feedback about feature set combinations projects are really using, and 
immediate feedback already even if some yet unreleased change would break 
something for any downstream project,

It is about saving time as you can see and being able to concentrate on things 
that really matter instead of having to write all those tests by yourself.

And downstream projects would benefit from probably having to maintain less 
Bison version checks, and/or being automatically informed very early about 
upcoming backward incompatibility issues to be handled and/or trying to react 
by sending a veto email to prevent that. :)

But just an idea ...

Best regards,
Christian Schoenebeck