On Tue, 3 Dec 2024 17:57:13 +0100
Hans Åberg wrote:
> In general, one tries to exploit tokens to do special things, which
> is also useful in a Bison parser when adding mid-rule actions.
That's good advice, hard-won.
> > it seems it is much easier to parse everything in the data section
> >
On Sun, 1 Dec 2024 21:10:31 -0500
Maury Markowitz wrote:
> > DATA { yy_push_state(data); }
>
> Is there a difference between yy_push_state(data) and BEGIN(data)?
Yes. As stated in the manual, BEGIN simply changes the start
condition. yy_push_state and yy_pop_state use a stack, so you can
retur
On Sun, 1 Dec 2024 10:07:45 -0500
Maury Markowitz wrote:
> DATA 10,20,HELLO,WORLD!
>
> I am looking for ways to attack this.
To add to what Hans said, you want to extend what the scanner accepts
in a DATA statement. In your case, DATA has a slightly more expansive
view of what an expression is
On Fri, 18 Oct 2024 10:19:52 +0200
Basile STARYNKEVITCH wrote:
> But I am unable to build that modified bison-refpersys on my Debian
> laptop?
I'm puzzled, because on the surface your question seems simple, and
completely within your capability. Is the following correct?
1. You did:
On Thu, 21 Dec 2023 18:42:05 -0500
Steve Litt wrote:
> So, on a high level, do I now have a good understanding of the
> definitions of "parser stack", "shift" and "reduce"?
Depending on how high is high, sure. :-)
See "5.5 Parser States" in the Bison manual. As yourself if you
understand th
On Wed, 20 Dec 2023 19:58:26 +0100
Dan Ohlsson wrote:
> I have difficulties understanding the stack content when executing
> bison with the -v options. Please explain or give reference to where
> I can find information!
That's a really big question, Dan. Do you want to come to Brussels in
Febr
On Wed, 13 Dec 2023 19:01:22 -0500
Steve Litt wrote:
> >.+/\n { ... return LINE; }
> >(\n[[:blank:]]*){2,} { return SEP; } // two or more blank lines
> >\n { /* ignore */ }
>
> Thanks James, this looks great!
You're welcome. It occurs to me that
.+/\n
is the same as
.
On Tue, 12 Dec 2023 23:06:14 -0500
Steve Litt wrote:
> I've already split paratext into multiple LINE tokens which represent
> a line without its NL, and now I'm thinking of splitting line into
> multiple chars ("[^\n]"). Perhaps this will make the rules less
> complicated, though longer.
Have t
On Wed, 13 Dec 2023 15:45:36 +
Lotfi via Users list for the GNU Bison parser generator
wrote:
> I am trying to run this command
>
> > gcc lex.yy.c synt3.tab.c -lfl -ly
>
> while synt3.tab.c is a file BISON produced.It seems that I do not
> have the -ly library. I am using an ubuntuOS, pleas
On Thu, 16 Nov 2023 12:20:48 +0100
Christian Schoenebeck wrote:
> "skeleton" refers to the common structure and parts of generated
> parsers that are independent of the specified tokens and grammar
> (i.e. language), so simply spoken the portions that are (more or
> less) copied verbatim, [...]
On Wed, 15 Nov 2023 12:35:31 +0100
Christian Schoenebeck wrote:
> > Not everyone needs to have an opinon!)
>
> That's not what I said, but as you are already asking for my opinion:
> overall I actually find the Bison user manual very well (not saying
> perfect),
Bison has seen a lot of technic
On Mon, 13 Nov 2023 20:15:44 +0100
Christian Schoenebeck wrote:
> > You tell me: what is a "Bison token code"?
>
> Look, I am not judging how well Bison is documented or what good/bad
> terminology Bison authors chose. It's not my business.
I appreciate that, Christian, really. FWIW, I think
On Mon, 13 Nov 2023 12:33:57 +0100
Christian Schoenebeck wrote:
> > When I look up #899, NOT, I get "NOT". But when I look up #900,
> > NE, I get "'<'" because that's the next element in yytname (900 -
> > 255).
> [...]
>
> Are you aware that yytname[] is indexed by "symbol-number", not by
> "t
On Mon, 13 Nov 2023 10:52:02 +0100
Hans Åberg wrote:
> > Let's start, shall we, with "is it a bug"?
>
> The parser knows how to translate token numbers into names for error
> messages, but there is no API for that as far as I know.
I disagree. Bison might know how to do that, but "the parser
On Sun, 12 Nov 2023 22:40:04 +0100
Hans Åberg wrote:
> > On Nov 12, 2023, at 00:06, James K. Lowden
> > wrote:
> >
> > I think the purpose of the yytname array is simple: for each token
> > (that is not a character), it holds a string with the token's name
On Sat, 11 Nov 2023 18:03:59 +0100
Hans Åberg wrote:
> On Nov 10, 2023, at 01:57, James K. Lowden
> wrote:
> >
> > I can't seem to look up token names in yytname correctly using enum
> > yytokentype.
> ?
> > When I look up #899, NOT, I get "NO
I can't seem to look up token names in yytname correctly using enum
yytokentype.
At the end of enum yytokentype, I have
END_UNSTRING = 893,/* END_UNSTRING */
END_WRITE = 894, /* END_WRITE */
END_IF = 895, /* END_IF */
THRU = 896,
On Wed, 19 Oct 2022 10:13:12 -0400
"James K. Lowden" wrote:
The problem is solved, but I don't understand why.
> Further study of the report shows identical terms use different
> states:
>
> 794 search_linear: SEARCH search_1_body ? search_1_cases
> 795
On Tue, 18 Oct 2022 13:02:21 -0400
"James K. Lowden" wrote:
> The grammar is meant to handle a series of phrases
>
> WHEN conditional search_stmts
> WHEN conditional search_stmts
Further study of the report shows identical terms use different states:
794
Either I have tickled a bug, or there's a simple explanation.
Below is a fragment of the current GCC Cobol grammar. (The compiler is
based on gcc; it's not yet officially part of the project.)
search_1_cases is a recursive rule. It takes 1 or more occurences of
search_1_case. Each search_
Hi,
I'm writing a parser for Cobol. If you know Cobol, you know that's a
mouthful. Cobol predates BNF, and sometimes it shows.
Parser:
https://git.symas.net/cobolworx/gcc-cobol/gcc/cobol/parse.y
Documentation of the verb:
https://www.ibm.com/docs/en/cobol-zos/6.2?topic=statements-unstring-
21 matches
Mail list logo
