bison-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RFC: generate the default semantic action


From: Akim Demaille
Subject: Re: RFC: generate the default semantic action
Date: Tue, 16 Oct 2018 07:13:41 +0200

Hi Rici,

> Le 16 oct. 2018 à 00:15, Rici Lake <address@hidden> a écrit :
> 
> (Apologies for not replying properly to the mail thread; I wasn't
> previously subscribed to this list.)

Well, it’s good that you came!

> On Sun, 14 Oct 2018, Akim Demaille wrote:
> 
>>   The simplest seems to be actually generating the default semantic
>>   action (in all languages/skeletons).  This makes the pre-action (that
>>   sets $$ to $1) useless.  But...  maybe some users depend on this, in
>>   spite of the comments that clearly warn againt this.  So let's not
>>   turn this off just yet.
> 
> Sorry, what is the "this" which comments clearly warn against?

The ’this’ was referring to the pre-action that initializes $$ to $1.

> There is a
> clear warning in the bison manual (and other places) against relying on $$
> to be initialised to anything meaningful in a production with an empty
> right-hand-side, but I don't recall having seen any warning against using
> the default action,

What piece of documentation are you referring to?

I found this:

  If you don't specify an action for a rule, Bison supplies a default:
  @address@hidden = $1}.}  Thus, the value of the first symbol in the rule
  becomes the value of the whole rule.  Of course, the default action is
  valid only if the two data types match.  There is no meaningful default
  action for an empty rule; every empty rule must have an explicit action
  unless the rule's value does not matter.

It does not state that something is run before the user action.

However, the comments in the generated code are quite explicit about
this.

  /* If YYLEN is nonzero, implement the default value of the action:
     '$$ = $1'.

     Otherwise, the following line sets YYVAL to garbage.
     This behavior is undocumented and Bison
     users should not rely upon it.  Assigning to YYVAL
     unconditionally makes the parser a bit smaller, and it avoids a
     GCC warning that YYVAL may be used uninitialized.  */

> and I believe it is quite common to rely on it.

Thanks for drawing our attention to this.


> Please note that the default action is *not* the same as { $$ = $1; }. As
> the Bison manual states:
> 
>> ... you may also provide a struct rather that a union, which may be handy
> if you want to track information for every symbol (such as preceding
> comments).

I should be blamed for this…
https://lists.gnu.org/archive/html/bison-patches/2013-02/msg00093.html

When I wrote it, I was not thinking about relying on the
pre-action to propagate information.

Yes, you are right, the pre-action is more than $$ = $1 (let’s not
call this the default action, which I understand as « what is done
when the user did not provide an action », and I believe that’s what
the documentation means too).


> It's not entirely clear how this feature is intended to be used, but it
> certainly can be used, and I know that there are bison projects which rely
> on it.

If you can find some examples, I’d be happy to use them when
testing Bison.  And possibly to see if there are better ways
to reach the goal.


> Here’s a small and uninspiring example of how it can be used:

Nice, thanks!  I’d like to put it in the test suite.  Did you sign
the FSF’s disclaimers?

>    else if (ch == '!')   { scanf("%ms", &yylval.context); continue; }

I didn’t know %ms.  Unfortunately my libc didn’t either :)


> This patch won't affect programs which rely on this feature, as far as I
> can see. But I wanted to highlight the issue because the road that follows
> this patch might inadvertently affect existing programs which count on the
> default action to be a copy of the *entire* semantic value.

No, I don’t think it changes anything, indeed.  Even type checking
is run before adding the explicit default action.  Your example
runs fine.




Well, I really want to release 3.2 soon, so I think that the safest
is to not change anything about the pre-action right now.  We keep
it in all languages for 3.2, and then we’ll spend some more time
thinking about the future.

Thanks a lot for the heads up!


reply via email to

[Prev in Thread] Current Thread [Next in Thread]