From: James A. Markevitch (jam@magic.com)
Date: Sun Nov 05 2000 - 15:41:07 PST
> > However, the new grammar saddly introduces a reduce/reduce conflict,
> > which makes the grammr non LALR(1) in practice, and hence impossible
> > to parse with yacc. [James might share with us his magic solution...]
...
> I don't recall the exact construct which requires the infinite lookahead,
> and need to run to a meeting, so I can't look it up. But, the "magic
> solution" to this is seriously seriously ugly; if I recall, it involves
> communication between the lexer and parser and an infinitely deep stack,
> but I am not positive.
I had a chance to think about this over the weekend, and now remember the
particular case.
Consider the following fragment of code:
and #delay_val (a, b, c, d)
(e, f, g);
Looks like a parameterized delay and two AND gates. No, there's no comma
at the end of the first line. What's up? delay_val is a constant function
and "a, b, c, d" are arguments being passed to it. This is just one unnamed
AND gate with an output "e" and inputs "f" and "g" and a delay specified by
a constant function call "delay_val(a,b,c,d)".
The grammar is unambiguous, but you need to scan all the way to the second
open paren to decide whether delay_val is to be treated as a parameter or
as a constant function call.
If we had seen (with the comma):
and #delay_val (a, b, c, d),
(e, f, g);
Then we would have two AND gates, and delay_val would be a parameter
specifying the delay.
Since we cannot rely on constant functions being declared before they are
used, we cannot cheat by looking in the symbol table to determine if delay_val
is a constant function or not.
James Markevitch
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:54:14 PDT
and
sponsored by Boyd Technology, Inc.