Re: GNU Bison: D language support

[Akim Demaille]

Hi!

> Le 11 févr. 2019 à 19:15, H. S. Teoh <address@hidden> a écrit :
> 
> On Sun, Feb 10, 2019 at 11:05:43AM +0100, Akim Demaille wrote:
> 
>> There are tons of papers that prove the correctness of the algorithm
>> implemented in Bison, so you should not feel worried about that.  Of
>> course, proving an algorithm and proving an implementation  is not the
>> same thing :)  Besides, the user is free to mess around in her
>> actions.  So if it's possible, what is purely generated code (without
>> bits from the user) should probably be trusted.  When it comes to user
>> actions, maybe we need to be more cautious.  An %define variable such
>> as api.parser.trusted maybe?  so that the user can declare herself if
>> she wants to claim so.
> 
> I apologize for not defining the terms I use before using them.

Nah...  I should have read about this elsewhere. Thanks for
this description!


> This is why I am wary of marking an entire auto-generated parser as
> @trusted.  The user has no practical way to verify the memory safety of
> the entire parser every time Bison generates a new version of it from
> the .y file.  Doing so would defeat the purpose of using Bison in the
> first place -- if you had to manually review all the generated code, you
> might as well have written the parser by hand yourself.  And even if you
> trust Bison to generate correct code, if there's a bug in Bison that
> somehow breaks memory safety then the @trusted label is unwarranted, and
> the user program's @safe-ty is compromised without warning, and the user
> has no recourse to fix the problem without debugging Bison himself (and
> spending the time/effort to understand the Bison code in order to debug
> it).

Well, I think I had understood @trusted as you described it,
but I find it less likely to do what you fear.  The user is
not granted the right to play with the union itself, the parser
generation deals with it, and it's type safe.  But anyway, it's
probably something that will be clearer (to both of us) when we move
forward.

But I see your point that "I find it less likely" is exactly not the
point of @safe/@trusted, which is about certainty.



>> I'm not sure you need this.  (So far) Bison calls yyerror only with a
>> single string: it assembles the error message before passing it to
>> yyerror.  So, at least for a start, you could keep yyerror's interface
>> simple: possibly location, then string.
> 
> What I meant was that the generated Bison parser could automatically
> detect the signature of yyerror, so that if it supported a location,
> Bison would pass the location, otherwise, just a string.  It's really
> quite simple:
> 
>       if ( ... /* error detected */) {
>               static if (is(yyerror(Location.init, "")))
>                       yyerror(curr_location, error_msg);
>               else static if (is(yyerror("")))
>                       yyerror(error_msg);
>               else static assert(0, "Unsupported yyerror signature");
>       }

I'm not saying it's hard to do, I'm just saying: I don't see the point.
Either you did not ask Bison to track locations, so of course yyerror
has no such argument, or you specified %location, in which case it is
there, period.  No need for instrospection at D time, it's all about
Bison time.

Cheers!