Re: GLR: modification of $1

[Paul Hilfinger]

> 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.

Personally, I find this prospect a bit distasteful.  Part of it is
knowing too much, I suppose: to me, writing ``$1 = E;'' suggests the 
computation of an inherited attribute, which of course it is not.  I
would just as soon avoid such constructs in Bison files to ease the
(some fictional future) transition to a full attribute system, when
they would mean something else.

The ``transition from LALR'' argument would be fine except that (1)
the feature as it stands is technically undefined (or "muddled", to
use Paul E's term), and (2) no such situation would arise in a newly
ported-to-GLR LALR(1) grammar (muddled or not), since LALR parsers
don't "split" (furthermore, I believe you will find that on an LALR
grammar, assignment to $1 in the GLR parser works the same as it does
in the LALR parser.)

When I've felt the need to do something like this in the past, I've
instead had the semantic values be (constant) pointers (whose
referents I can modify at will).  With the current trend toward boxed
OOP language practices, this sort of hack has become more common.

But finally, it would take a certain implementation effort to realize
your proposed semantics.  At the moment, the semantic actions are
evaluated in a split parser by first copying semantic values from the
graph structure representing the set of parse stacks to an array,
whence they may be referenced by essentially the same algorithm used
in the LALR skeleton.  Implementing assignment to $1 would require
either copying back to the graph (a waste of time in the normal case),
or accessing $n using a different algorithm.  

Furthermore, I've had thoughts about introducing ``instant'' semantic
actions, which would take place immediately upon any reduction---
whether or not the stack was currently split, and regardless of
whether the particular stack involved was destined to die.  In these
cases, storing into $n can cause non-deterministic behavior
(especially since the sharing structure---which $n's will be seen by
which parses---is not always clear from a grammar).

Paul Hilfinger