On Saturday 28 June 2014 23:59:44 Ron Burk wrote:
> IMO, if the user has to read the code generated by the parser generator,
> then it has already failed to deliver on its fundamental premise.
Yep. But currently you have to read the code, at least if you want to use
Bison generated parsers for p
On 28 Jun 2014, at 12:33, Christian Schoenebeck
wrote:
> On Friday 27 June 2014 18:12:34 Hans Aberg wrote:
>> On 27 Jun 2014, at 14:40, Christian Schoenebeck
> wrote:
>>> 1. Strong separation between "lexer" and "parser" has its historical
>>>
>>>reasons, but it makes things o
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
On Friday 27 June 2014 18:12:34 Hans Aberg wrote:
> On 27 Jun 2014, at 14:40, Christian Schoenebeck
wrote:
> > 1. Strong separation between "lexer" and "parser" has its historical
> >
> >reasons, but it makes things often quite problematic.
>
> Bison is synced in the first hand
On 27 Jun 2014, at 14:40, Christian Schoenebeck
wrote:
> 1. Strong separation between "lexer" and "parser" has its historical
> reasons, but it makes things often quite problematic.
Bison is synced in the first hand with Flex, but the latter does not currently
belong to the GNU
On Wednesday 25 June 2014 23:00:10 Hans Aberg wrote:
> If you want your interpreter to read and interact token-by-token, then you
> should use the push parser. If you further want to show correct token
> completions, then an LR(1) parser should be used: the Bison default is
> LALR(1), which has sta
On 19 Jun 2014, at 04:53, Grant McKenzie wrote:
> I would eventually like to implement a simple command line interface to my
> little language. I understand that I can set yyin to some stream that I
> control from as-yet-to-be-implemented command line interface. That interface
> would also man
> 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
Hey Grant,
I don't know the internals of how python and shells do it, but a project I
worked on a long time ago did it a completely different way. They
implemented two grammars: one was the real language grammar (used for
reading in scripts from files), and the second would parse just an isolated
Hello,
I have been going through the very nice "A Complete C++ Example" in the
bison manual and extending it to implement a trivial language. I have a
question about the parsing driver design on this page:
http://www.gnu.org/software/bison/manual/html_node/Calc_002b_002b-Parsing-Driver.html#C
10 matches
Mail list logo
