Re: GLR: modification of $1

[Frank Heckenbach]

Paul Eggert wrote:

> Frank Heckenbach <address@hidden> writes:
> 
> > Perhaps a stupid question, but are the `$1' etc. variables read-only
> > (in particular, in mid-rule actions)?
> 
> Traditionally, they were read-write.  The POSIX spec is muddled in
> this area.  However, even if it clearly stated that they are
> read-write, that requirement would apply only to the traditional
> yacc.c template; it wouldn't apply to the GLR template.

I suppose POSIX doesn't say anything about GLR. But IMHO it would be
a good idea to have it behave like the traditional yacc.c as much as
possible to avoid making "porting" from LALR to GLR more difficult
than necessary.

> > The examples in the documentation don't seem to modify
> > them, but other parsers do (e.g., the gcc C parser does so for
> > handling `&&' etc.).
> 
> (Blush.)  I'm responsible for some of those contorted grammars.
>
> > If modification is actually allowed, there seems to be a bug in the
> > GLR parser (tested with 1.875b since I can't easily build the CVS
> > versions).
> 
> If modification is not allowed in GLR parsers, perhaps glr.c should be
> changed so that $1 expands to a const-qualified object; that way,
> errors will be caught at compile-time.

I'd think so. The following q&d change seems to achieve this and
shows me the critical statements in my actions. (Patch taken against
my generated parser, not glr.c, but you don't want to apply that to
bison, anyway.)

--- parse.c.orig        Thu Oct  2 18:23:40 2003
+++ parse.c     Thu Oct  2 18:29:06 2003
@@ -4520,7 +4520,7 @@
  *  (@$). Returns yyok for normal return, yyaccept for YYACCEPT,
  *  yyerr for YYERROR, yyabort for YYABORT. */
 static YYRESULTTAG
-yyuserAction (yyRuleNum yyn, int yyrhslen, yyGLRStackItem* yyvsp,
+yyuserAction (yyRuleNum yyn, int yyrhslen, const yyGLRStackItem* yyvsp,
              YYSTYPE* yyvalp, YYLTYPE* yylocp, yyGLRStack* yystack
               )
 {
@@ -4540,7 +4540,7 @@
 # undef yyclearin
 # define yyclearin (yychar = *(yystack->yytokenp) = YYEMPTY)
 # undef YYFILL
-# define YYFILL(N) yyfill (yyvsp, &yylow, N, yynormal)
+# define YYFILL(N) yyfill ((yyGLRStackItem *) yyvsp, &yylow, N, yynormal)
 # undef YYBACKUP
 # define YYBACKUP(Token, Value)                                                
     \
   return yyerror ("syntax error: cannot back up"),          \

But rather than this I'd prefer if $1 would be writable. This would
give the grammar writer more freedom in the actions, and require
fewer changes to an existing LALR grammar.

E.g., in the `&&' case of GNU C, it would be easily possible to
assign to `$<ttype>$' instead of `$1' in the mid-rule action. But
when an action wants to store several values, I've always found it
useful to be able to put them in $1, ... as well (such as the action
for `?:' without middle-part in GNU C which stores in both $1 and
$2). If that's not possible, the only alternative seems to put the
things in a list or something (with more runtime and memory
overhead, of course).

I'm not familiar with the implementation details of GLR. The
description in the manual says:

:    During the time that there are multiple parsers, semantic actions are
: recorded, but not performed.  When a parser disappears, its recorded
: semantic actions disappear as well, and are never performed.  When a
: reduction makes two parsers identical, causing them to merge, Bison
: records both sets of semantic actions.  Whenever the last two parsers
: merge, reverting to the single-parser case, Bison resolves all the
: outstanding actions either by precedences given to the grammar rules
: involved, or by performing both actions, and then calling a designated
: user-defined function on the resulting values to produce an arbitrary
: merged result.

In the last case I could imagine a problem writing to $1. But if
only one resolution is ever performed, there should be no problem.
(Either by dynamic precedences, or because only one of the clones
doesn't run into a parsing error and disappear -- the latter is
always the case in my grammar, i.e. I basically use GLR as a way to
achieve more look-ahead, while there are no actual ambiguities in my
language.)

What I'd like to know now is if there's a chance that $1 will be
writable with GLR in the future, or if I have to start rewriting my
actions.

Frank

-- 
Frank Heckenbach, address@hidden
http://fjf.gnu.de/
GnuPG and PGP keys: http://fjf.gnu.de/plan (7977168E)