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 a
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 Bur
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 guess
> For scripting language implementations, I tend to disagree.
The rule that lexing costs outweigh parsing is very old and pretty
consistent. I recall getting a ~40% speedup from changing one
assembly-language instruction in the tokenizer of a text processor on the
old Honeywell mainframe. However,
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, bis
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 (an
> I somehow need to send an indication from bison to flex to my interface
that syntax is incomplete.
Yes. Any number of ways of moving that bit, any way that pleases you will
work.
> my thinking here was that I could examine the stack depth each time yylex
was called
Probably not the way you wan
> 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 expressio
In my own parser generator tinkering (where I care greatly about
explanations), I would say:
'list' is a nonterminal that never terminates.
and link to a longer explanation of that concept.
This is probably the most succinct diagnostic,
since the problem is not what any of the 'list'
rules does
On Fri, Sep 13, 2013 at 1:42 AM, 王波 wrote:
>I think Bison should support this way.
I don't think so. It's a specific case of this general problem:
you have a lexer and a parser, you've made the parser depend on state
in the lexer, but that has the potential to make your parser depend on
the v
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 constructs
When almost everything is a legal parse, a parser generator begins
to fail to be a good match for the problem. When hand-written C is
clearer, better able to identify errors, and possibly even shorter
than the grammar equivalent, then I figure it's probably not a job
for a parser generator.
Person
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
Preferring a lexer that doesn't expose state to the parser:
a) lexer emits TK_GT for "normal" '>'
b) lexer emits two tokens for '>>': TK_GT1 TK_GT2
c) in non-template area of grammar, use non-terminal to refer to '>>'
operator:
rshift : TK_GT1 TK_GT2
d) in template area of grammar, use non
14 matches
Mail list logo
