i'm new to Flex and Bison and are currently reading the book "Flex and
Bison" and have a few troubles understanding things correctly.
First of all i've troubles compiling the first example that uses both,
Flex and Bison. Flex compilation was easy but with Biton i've troubles,
first the exampl
I've missed to remove some code from the lexer.l file:
%{
#include
#include
#include "./parser.tab.h"
enum yytokentype {
NUMBER = 285,
VAL = 292,
ADD = 286,
SUB = 287,
MUL = 288,
DIV = 289,
ABS = 290,
EOL = 291
};
int yylval;
char *value = NULL;
I've managed to come a bit more forward, now my lexer.l files look like
this:
%{
#include
#include
#include "./parser.tab.h"
enum yytokentype {
NUMBER = 285,
VAL = 292,
ADD = 286,
SUB = 287,
MUL = 288,
DIV = 289,
ABS = 290,
EOL = 291
};
int yylval;
%}
%%
"+
Hi,
review your Makefile, it has errors. Read the Make docs,
the basic use is:
TARGET: DEPENDENCIES
ACTIONS_THAT_USE_DEPENDENCIES_TO_UPDATE_TARGET
You might want to try emulating Yacc if the booking you
are using is enough old and in case current Bison could
not be able to really foll
So my Bison and Flex code is out of date ?
On 17.02.19 13:04, Uxio Prego wrote:
Hi,
review your Makefile, it has errors. Read the Make docs,
the basic use is:
TARGET: DEPENDENCIES
ACTIONS_THAT_USE_DEPENDENCIES_TO_UPDATE_TARGET
You might want to try emulating Yacc if the booking
For a beginner it's hard to find what i've to write, on what
documentation should i refer to ? to original bison & flex manual
respectiveley ?
best regards!
On 17.02.19 13:22, workbe...@gmx.at wrote:
So my Bison and Flex code is out of date ?
On 17.02.19 13:04, Uxio Prego wrote:
Hi,
revi
Hi,
The more I study flex/bison, the more confused I got about when to use
what actions and what to put in lexer and what to put in grammar.
For example, for an assignment,
x=10
it can be processed by the lexer,
[[:alpha:]_][[:alnum:]_]=[[:digit:]+] { /* parse yytext to get the
name and value
Is there a way i can put my c source code not inside one the the lexer.l
or parser.y files ? so i can keep tem separate from the rules ?
best regards!
On 17.02.19 13:24, workbe...@gmx.at wrote:
For a beginner it's hard to find what i've to write, on what
documentation should i refer to ? to o
Hi!
> Le 17 févr. 2019 à 14:08, Peng Yu a écrit :
>
> Hi,
>
> The more I study flex/bison, the more confused I got about when to use
> what actions and what to put in lexer and what to put in grammar.
Usually it's quite clear: build words from letters in the scanner,
build sentences from words
Yes of course, by inclusion of headers, in a very much
common way. You can then manipulate shorter *.y and
*.l docs, but this is not going to fix any Bison usage issue
you are having.
If yours is a serious book, it should have made a small
annex stating which versions of Flex and Bison the book
ex
Hi,
>> I can't get i compile and if i get i compile by hand i get errors ...
>> please can someone help me out here,
>> the book doens't go to much into detail about this topic.
Can't help without actual commands and actual error messages.
> Le 17 févr. 2019 à 14:17, workbe...@gmx.
>> Le 17 févr. 2019 à 14:17, workbe...@gmx.at a écrit :
>>
>> Is there a way i can put my c source code not inside one the the lexer.l or
>> parser.y files ? so i can keep tem separate from the rules ?
Two opposite answers:
I said:
> Le 17 févr. 2019 à 15:49, Akim Demaille a écrit :
>
> N
> Le 10 févr. 2019 à 15:10, Hans Åberg a écrit :
>
>
>> On 5 Feb 2019, at 07:18, Akim Demaille wrote:
>>
>> This feature is very handy for small grammars, but when it gets too big,
>> you'd better look at the HTML report (or text).
>
> I made a graph for the grammar itself, using the shape
> Le 10 févr. 2019 à 15:20, Hans Åberg a écrit :
>
>> On 10 Feb 2019, at 11:07, Akim Demaille wrote:
>>
>> [*.dot vs. *.gv]
>> But it's too late to change the default behavior.
>
> You might change it, as it is not usable on real life grammars.
You have a point :)
But it does not mean it wi
Hi Anand,
Sorry, I missed your message :(
> Le 14 févr. 2019 à 07:05, an...@aakhare.in a écrit :
>
> Hello Akim,
>consider simple example below
>
> expr : a
> | expr + b {
> $$ = $1 + $2;
> }
> | expr * b {
>
Sometimes, the best implementation may not be what it obviously should
look like. I think that there can be cases in which more actions
should be in the lexer instead of the parser.
Consider the parameter expansion (along with assignment) in bash.
https://www.gnu.org/software/bash/manual/html_nod
> On 17 Feb 2019, at 16:18, Akim Demaille wrote:
>
>> Le 10 févr. 2019 à 15:10, Hans Åberg a écrit :
>>
>>
>>> On 5 Feb 2019, at 07:18, Akim Demaille wrote:
>>>
>>> This feature is very handy for small grammars, but when it gets too big,
>>> you'd better look at the HTML report (or text).
> On 17 Feb 2019, at 17:36, Peng Yu wrote:
>
> But how to recognize the nested parameter expansion assignment in the
> first place? The lexer should have builtin states to capture paired
> `{` `}`, and use states to remember whether it is in substring
> extraction or pattern replacement in orde
Hi Peng,
> Le 17 févr. 2019 à 17:36, Peng Yu a écrit :
>
> Sometimes, the best implementation may not be what it obviously should
> look like. I think that there can be cases in which more actions
> should be in the lexer instead of the parser.
Yes, I agree.
> Consider the parameter expansion
Now a very simple question: i have this lexer.l file:
%{
#include
#include
enum yytokentype {
NUMBER = 285,
VAL = 292,
ADD = 286,
SUB = 287,
MUL = 288,
DIV = 289,
ABS = 290,
EOL = 291,
STRING = 292
};
int yylval;
char yyltext[256];
%}
%%
"+"
Hi,
On 17.02.19 14:08, Peng Yu wrote:
> [[:alpha:]_][[:alnum:]_]=[[:digit:]+] { /* parse yytext to get the
> name and value, then do the assignment */ }
The main reason you are using a lexer is to avoid writing code for
manual parsing. The lexer can already tell you where the equals sign is
and
What are you feeding?
What is happening?
What are you expecting instead?
> On 17 Feb 2019, at 18:43, workbe...@gmx.at wrote:
>
> Now a very simple question: i have this lexer.l file:
>
> [...]
> [a-zA-Z]{ strcpy(yytext, yyltext); return STRING; }
> [0-9]+{ yylval = atoi(yytext); ret
I found the solution, my [a-zA-Z] had not + at the end so he only
recognized single characters instead of strings.. now it's working, thank
best reagrds!
On 17.02.19 19:51, Uxio Prego wrote:
What are you feeding?
What is happening?
What are you expecting instead?
On 17 Feb 2019, at 18:43, wo
> On 17 Feb 2019, at 16:19, Akim Demaille wrote:
>
>> Le 10 févr. 2019 à 15:20, Hans Åberg a écrit :
>>
>>> On 10 Feb 2019, at 11:07, Akim Demaille wrote:
>>>
>>> [*.dot vs. *.gv]
>>> But it's too late to change the default behavior.
>>
>> You might change it, as it is not usable on real li
This lexical tie-in creates feedback from the parser to the lexer. So
the lexer cannot be tested standalone.
But the principle of separating lexer and parser is to make parser
builtin on top of the parser. Is there something that can avoid the
feedback yet still allow context-dependent parsing? Al
> On 17 Feb 2019, at 23:10, Peng Yu wrote:
>
> This lexical tie-in creates feedback from the parser to the lexer. So
> the lexer cannot be tested standalone.
>
> But the principle of separating lexer and parser is to make parser
> builtin on top of the parser. Is there something that can avoid
Hi,
I have the following toy flex code to generate a lexer.
I use rapidstring to make the string operations use and use the Boehm
garbage collector so that I don't have to always remember to release
the memory.
https://github.com/boyerjohn/rapidstring
Because I want to use the previously alloca
I think the following should fix the compile errors. Presumably they are
prompted by compilers more sensitive nowadays than they were back in the days
when this book was written:
- lexer.l: remove the declaration enum yytokentype which is shipped by
including parser.tab.h
- parser.y: add forwar
On Sun, 17 Feb 2019 18:43:38 +0100, workbe...@gmx.at wrote:
> Now a very simple question: i have this lexer.l file:
Suggestions for lines you might want to use instead to get things up and
running:
> [a-zA-Z]{ strcpy(yytext, yyltext); return STRING; }
[a-zA-Z]+{ strcpy(yyltext, yytext
Hi Peng!
> Le 17 févr. 2019 à 23:10, Peng Yu a écrit :
>
> This lexical tie-in creates feedback from the parser to the lexer. So
> the lexer cannot be tested standalone.
Well, yes, it can, but that's not as elegant, agreed.
> But the principle of separating lexer and parser is to make parser
>
> Le 18 févr. 2019 à 00:10, Hans Åberg a écrit :
>
>
>> On 17 Feb 2019, at 23:10, Peng Yu wrote:
>>
>> This lexical tie-in creates feedback from the parser to the lexer. So
>> the lexer cannot be tested standalone.
>>
>> But the principle of separating lexer and parser is to make parser
>>
> Le 17 févr. 2019 à 23:00, Hans Åberg a écrit :
>
>> On 17 Feb 2019, at 16:19, Akim Demaille wrote:
>>
>>> Le 10 févr. 2019 à 15:20, Hans Åberg a écrit :
>>>
On 10 Feb 2019, at 11:07, Akim Demaille wrote:
[*.dot vs. *.gv]
But it's too late to change the default behavi
32 matches
Mail list logo
