> 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
> 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
>>
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
>
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
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
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
> 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
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 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
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
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
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
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 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
> 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
> 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).
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
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 {
>
> 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
> 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 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
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.
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!
> 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
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,
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
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
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
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
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;
%}
%%
"+
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'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
32 matches
Mail list logo
