Re: GLR: modification of $1

[Frank Heckenbach]

Hans Aberg wrote:

> At 15:31 -0700 2003/10/02, Paul Hilfinger wrote:
> >> 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.
> 
> It has been discussed here before, in the case of non-GLR parser, people
> wanting
> to make special rule midaction tweaks which works under the special C stack
> array implementation. In those cases, it then turns out that such
> constructs can pose problems when stacks are implemented say under C++ not
> using any simple array structure like under C. The problem is that the
> midactions are implemented by introducing an anonymous rule, and one can
> not in more general stack implementations expect values to survive on such
> stacks. Thus, this is the same problem as in the case of the GLR parser:
> One uses more general types of stack models, simply. Clearly the general
> Bison framework should not rely on any particular C stack implementation
> model which will not work under other languages, or other more general
> implementations.

It's ok by me. I'm just changing my grammar. It's a bit of work, but
no real problem.

> So this suggests that one, at least for now, should only admit a rule
> midaction to assign to its $$ value, and it can only use the $n values
> referring to the variables/tokens/midactions before it in the rule. If the
> $n values can be implemented as const values, that seems to be an advantage
> under this model.

I'd second this -- and suggest that it be clearly stated in the
documentation (either for GLR or in general, whichever is the actual
intention).

Frank

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