His goof was to specify '=' (three characters) in flex. So the = token
never got to the parser.
On 11/28/20 09:49, Akim Demaille wrote:
Hi Jot,
Le 27 nov. 2020 à 11:20, Jot Dot a écrit :
What do you mean? It did display "go to state 31", but did not? Could you
please provide us with the
First of all, my commiserations.
Second, you need to deal with this in the scanner, not in the parser.
Essentially, any scanner that processes random data (aka comment) as if
it were program statements is going to fail miserably. And so will any
parser that attempts to make sense of the maels
What is the purpose of this declaration in the generated C file:
extern int yylex (void);
I can see that I can define a macro to turn it off, but it seems to
serve no purpose as the function is defined anyhow about fifteen lines
below. I suppose a purist might even object to "extern".
You'll ge
010, at 10:56, John P. Hartmann wrote:
>
>> What is the purpose of this declaration in the generated C file:
>>
>> extern int yylex (void);
>>
>> I can see that I can define a macro to turn it off, but it seems to
>> serve no purpose as the function is defined a
Just rebuild Bison 2.4.3 from source, which downloaded from the gnu
site. On Fedora 13.
I'm using location information using my own struct yylloc as I also
want information on the origin file.
The generated C code shows that it is there, but even so there are two problems:
1. There is no posit
-- Forwarded message --
From: John P. Hartmann
Date: 24 August 2010 15:59
Subject: Re: Parser generated on Bison 1.5 (and later) does not start a parsing
To: Baruch Gudesblat
Add %error-verbose to the declarations section and set yydebug=1
before calling the parser.
j.
On
As I consider any warnings from Bison to be errors,I'd like to stop
the build process right there; it is sometimes hard to spot a warning
in all the babble.
Yes, I can make xxx.c and see the warnings, but it would be much more
convenient not to have to resort to that.
Thanks,
j.
-- Forwarded message --
From: John P. Hartmann
Date: 1 September 2010 07:49
Subject: Re: grammar for propositional logic
To: Martin McDermott
You should inspect the .output file to resolve your conflicts. For
something as simple as yours, you should have zero tolerance for
If you mean why do you get the shift/reduce errors, it is because your
grammar is ambiguous.
You can deal with the ambiguity in several ways, but %left to specify
associativity and precedence as I said earlier seems like the easiest
in your case.
Doing that will remove all conflicts from your gra
Essentially, your input does not conform to your grammar (but you
probably know that).
%error-verbose will give you more information about where the grammar
and your input disagree.
Set yydebug=1 to get a trace of the parse. With that, inspect
y.output for the failing state.
j.
Aha!
$undefined means that the lexer returned a character value that you
are not prepared for, that is, it is not in a rule or %token in your
grammar file. Bison could have been a bit more cooperative by telling
you which character it is, but there you are.
Assuming the lexer is flex, %option d
You didn't turn on debugging in flex, which is why it doesn't tell you
anything.
Assuming you don't care about whitespace, you need to split the rule
on line 39 into
[ \t\r] ;
[\n] {lexEcho("%s", yytext); return yytext[0];}
The default rule needs to return something
> --accepting rule at line 28 ("NOT")
> --accepting rule at line 36 (" ")
> --accepting rule at line 33 ("r")
> --accepting rule at line 37 ("
> ")
>
> --(end of buffer or a NUL)
> --EOF (start condition 0)
> syntax error, unexpect
While Bison has only one token lookahead, it has infinite memory. If
something is optional it is best to write two reduction rules. Though
the combinations do grow exponentially. In your case:
syntax1 : decl_spec ';'
| decl_spec init_spec ';'
| decl_spec init_spec decl_attrib ';'
| decl_s
>From a cursory instpection of an output C file, I think that
#define YYTYPE_INT16 int
would make the stack wider. I don't know what other side effects, if
any, there may be.
j.
2010/9/21 Håkan Johansson :
> I'm using gcc with the option -Wconversion (and -Werror), which gives a
> warning in
Use exclusive start conditions. Have flex (or a wrapper) issue a token that
is particular to the situation at hand. Of course, you are carrying the
overhead of larger tables.
On 6 February 2011 14:39, Martin Alexander Neumann <
hotpotatorout...@googlemail.com> wrote:
> Hi,
>
> some time ago I d
I need to weigh in here too. I use Bison in "table-only" mode. Any
change in the table structure would require me to make a corresponding
change in my post processor. Any radical change would mean that I
would be stuck with a downlevel Bison.
On 6 April 2011 14:35, David M. Warme wrote:
>
> Bi
E.g., taking the tables to an architecture where there is no native Bison.
On 6 April 2011 21:06, Akim Demaille wrote:
>
> hi all,
>
> I would really like to know more about your uses of Bison. What kind of use
> can require these tables?
>
> Cheers,
>
> Akim
>
>
___
That is probably much easier to handle by exclusive start conditions
in the scanner.
On 23 July 2011 02:40, uclacasey wrote:
>
> I'm writing a program that handles comments as well as a few other things. If
> a comment is in a specific place, then my program does something.
>
> Flex passes a toke
Well, controlling the scanner from the parser is never going to work
in general as the scanner can be way ahead. I'm afraid you'll have to
write a parallel "parser" using exclusive star conditions. However
this "parser" can be vastly simplified as it only has to figure out
whether to return a com
From: Ludovic Courtès
Date: 25 July 2011 12:14
Subject: Re: Stopping as soon as a valid symbol is read
To: "John P. Hartmann"
"John P. Hartmann" skribis:
> Is a+b an expression? You don't know until you see something that is
> not an operator, it might be a+
Welcome, Matt!
Scanning strings is something for flex to do, if the strings are
constant. If you wish to change the set of valid strings dynamically
or "often", you'll need to add them to a dictionary and search that
dictionary in bison. Constructing a dictionary is simple with stuff
like tsearc
I have a fine grammar, but I get unset value warnings in droves when I add
empty %destructor declartions (the error token is not [yet] referenced).
This applies to Bison 2.5 on Fedora 17 and also 2.4.1 on Fedora13.
%union
{
struct instruction * inst;
struct expression * exp;
struct term
Thanks, Akim.
Right, so it is the presence of a destructor that enables this
checking. Might it be worth mentioning in the documentation?
The example in 3.8.7 shows how to use
%destructor { }
it probably confused me. The explanation certainly doesn't tell me
all the ramifications.
-
Tr
But here is another one:
| dotobyfors dotobyfor { listend($1, $2); }
Gets "warning: unset value: $$".
I'm relying on the default $$ = $1 here.
Or is there something more subtle going on? Or (shudder) is the
default applied only when there is no explicit semantic code? (In
whic
:43, John P. Hartmann wrote:
> But here is another one:
>
>| dotobyfors dotobyfor { listend($1, $2); }
>
> Gets "warning: unset value: $$".
>
> I'm relying on the default $$ = $1 here.
>
> Or is there something more subtle going on? Or
Demaille wrote:
>
> Le 28 janv. 2013 à 17:11, John P. Hartmann a écrit :
>
>> On 28 January 2013 16:43, John P. Hartmann wrote:
>>> But here is another one:
>>>
>>> | dotobyfors dotobyfor { listend($1, $2); }
>>>
>>> Gets &q
:-) Well done.
Those comments weren't there ten years ago.
On 28 January 2013 18:17, Akim Demaille wrote:
>
> Le 28 janv. 2013 à 18:14, "John P. Hartmann" a écrit :
>
>> Thank you for the clarification. I see.
>>
>> I guess I am handicapped b
Isn't the point that <> are brackets (parentheses) in this context.
Clearly the lexer must determine this and emit an appropriate token.
On 6 February 2013 10:14, Hans Aberg wrote:
> On 6 Feb 2013, at 00:54, Adam Smalin wrote:
>
>> This doesn't help :( I see >> is in the lexer (search SHL) which
! is a prefix operator; = is infix.
On 11/19/2013 09:50 AM, Florent Teichteil wrote:
> Thanks John!
> One question though: why do the precedence levels of operators '!' and
> '=' defined at the beginning of my grammar don't apply in this case?
> Moreover, I thought that ambiguous associativity was
You'll have to learn to decipher the grammar output file. Perhaps the
problem is the rule
num_expr : bool_expr
You are welcome to send me the output file as a mail attachment off his
list.
On 11/19/2013 11:40 AM, Florent Teichteil wrote:
>> ! is a prefix operator; = is infix.
>
> Sorry, but I
%error-verbose
%right '='
%left '+'
%token IDENTIFIER INTEGER CALL
%%
expression: IDENTIFIER '=' expression
| expression '+' expression
| '( ' expression ')'
| primary
primary: IDENTIFIER
| INTEGER
| CALL '(' expressi
actually i think i am getting confused i will make a test case to show it.
>
>
> On 29 November 2013 11:54, Philip Herron wrote:
>
>> hmm not sure should i use this: does it mean i should use flex to look at
>> the next token if it '('.
>>
>>
The parser can control the lexer, but you must be careful to do this
only when that parser does not need a lookahead token, lest the two get
out of sync.
On 10/11/2016 08:58 PM, guillaume marques wrote:
On 11 Oct 2016, at 20:50, haber...@telia.com wrote:
In the manual of Bison 3.0.4, 7.2 Lex
You will have to do that in the scanner using exclusive start states.
When it meets blanks after a NUMBER or ID, it emits the SPACE token if
the beginning of a number or identifier follows the blank(s):
{
[ \t]+/[a-z0-9] BEGIN(INITIAL); return SPACE;
[ \t]+ BEGIN(INITIA
Bison contains no embargoed software, in particular, no encryption.
Thus no ECCN has been assigned.
Perhaps you could seek help at whoever gave you the impression that you
have an obligation to provide something that does not exist?
On 04/05/2018 09:08 AM, COFFIN, Barry [UK] wrote:
Hans,
Th
Congratulations on reading the manual.
You clearly think that flex matches a line at a time. Not so. Perhaps
read the books to the end first?
On 2/22/19 15:00, workbe...@gmx.at wrote:
Now my question is when i enter one of the verbs it's working normaly
like expected, but when i enter for
This warning is introduced between 3.0.2 and 3.0.4 as far as I can tell.
Is there a way to stop bison adding gratuitous stuff to the actions
other than $ and @ processing?
Do remember that we are a band of merry men who write IBM System/360
assembler in the actions.
We still bemoan the loss
Alas, the scanner is allowed to return an integer only. It cannot
return a string.
Anyhow, your sample %token statement declares two tokens, not one; the
last being meaningless.
On 3/2/19 21:13, Derek Clegg wrote:
On Feb 18, 2019, at 9:59 PM, Akim Demaille wrote:
Hi Derek,
Le 18 févr.
Not what you asked for (each keystroke individually), but look into
#define YY_USER_ACTION
It has ytext and yyleng for you.
On 4/26/19 11:26, Rainer Gerhards wrote:
Hi there,
sorry if there is an obvious solution - I didn't find it.
I have a config file parser created with flex/bison. It inc
For the scanner and parser I maintain on UNIX and then transport to the
EBCDIC world of the mainframe, I had to write my own scanner, but I can
get by with Bison as long as I don't use character constants in rules
(IBM 360 assembler in rules does work). There were a few other hoops,
such as no
On 7/6/20 06:36, Akim Demaille wrote:
I don't think you ever posted a snippet of that grammar of yours. I
suppose there are IP issues, but maybe you could share just a small
bit, or a fake example, so that we can have a better idea of it?
I did send you one years ago, but here goes again. You
On 7/7/20 05:35, Akim Demaille wrote:
I believe you need to read again the documentation of /
'r/s'
It is not as simple as that. As I don't speak BASIC, let me rephrase
this problem in FORTRAN IV which is also "blank agnostic":
DO = , [, ]
It is not until you reach the comma after the
On 7/26/20 10:56, Akim Demaille wrote:
The most frequent cited good reasons to write parsers by hand is:
3. tailored error messages
Instead of some dummy "unexpected foo, expected bar or baz", writing
something really helping.
All you have to do is write a rule for the incorrect construc
44 matches
Mail list logo