Top-of-head musings that are guaranteed to be confused, incomplete, and
wrong:
Seems like, roughly speaking, semicolons are optional, but if not present
must be replaced by a newline. The primary complication being we otherwise
want to ignore newlines. So, if I augment the token value to include
eam of the first
> expr in 'expr SINGLE_SPACE_OP expr' has not reduced to expr yet. It was
> still ID by the time Flex scan SINGLE_SPACE. The suggestion from Bison
> document Lexical Tie-ins section only works for the terminal case.
>
>
> On Fri, Dec 2, 2016 at 1:25 AM, Ron Burk <ron
Hi Ricky,
Just curious: What actually terminates an 'expr' production? For example,
if they were terminated by newlines and the parser encountered this token
stream:
ID SINGLE_SPACE '\n'
do you intend to treat that as a "missing right-hand-side of SINGLE_SPACE
operator" error?
Likewise, I
Your solution attempts to modify lexer state from the parser,
which ties you to what would, ideally, be the implementation-dependent
details of precisely when the parser invokes the lexer.
Also seems like your solution only catches one side of the issue,
if I've understood it correctly.
AFAIK,
You make many excellent points that I want to disagree with :-)
1. Strong separation between lexer and parser has its historical
reasons, but it makes things often quite problematic. There are ways
to deal with that of course, but it makes the .y /.l files (and
because it would be wrong when looking into functions.
Is there some reason you need to treat function parameter lists
as expressions, rather than comma-separated expression lists?
Could you just follow the usual practice of:
a) give ',' and '=' the precedence you desire
b) break your
If I've understood correct, two points come to mind:
a) exp : exp exp | ...
Seems highly ambiguous for no good reason. BTW, did you
really want to exclude the possibility of productions that have
only one symbol on the right-hand side? Not sure why you
wouldn't use very standard/common
Seems like it would be (more than) helpful if Bison would report
any use of %dprec that will fail to actually affect the resulting parser!
___
help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison
