Re: how to solve this reduce/reduce conflict?

Hi, > Le 21 sept. 2022 à 23:31, Lukas Arsalan a écrit : > > exp: >"-" "num"{ $$ = -*new Float($2); std::cout << "NUMinv" << $$ > << std::endl; } > | "num"{ $$ = new Float($1); std::cout << "num" << $$ << > std::endl; } > | "-" exp { $$ = -*$2;

Re: Language Versions

Arthur, > Le 15 sept. 2022 à 22:59, Arthur Schwarz a écrit : > >> Hi; >> >>> This is no more than a single line in the document and/or part of --help. >>> It tells your audience what compilers they can use and what language >>> elements are available. All with a single line. >> >> No can

Re: Questions on 3.4.6 Actions

Hi Arthur, > Le 15 sept. 2022 à 23:11, Arthur Schwarz a écrit : > > Hi Akim; > > You seem to be the go-to person for Harsh and Unremitting Criticism; sorry. I don't know how to read your sentence :) It's ambiguous to me. But reports are welcome. You made many of them, unfortunately during

Re: Questions on 3.4.6 Actions

And yes, it does. > > Definition: > LHS left hand size LHS : RHS > RHS right hand side LHS : RHS > > Are these assumptions correct. Most statements are true, except the ones I answered to. I will add the following patch to the documentation to clarify fuzzy bits. T

Re: Language Versions

Hi Arthur, > Le 6 sept. 2022 à 23:05, Arthur Schwarz a écrit : > > Hi Akim; > > I do mean the version of C/C++/D/Java should be stated. It does make sense. > For example int he C case there is the K & R version. We aim at C90. KnR support was dropped long ago: > * Noteworthy changes in

Re: Porting bison to z/OS (ASCII based)

Hi Mike, > Le 27 mai 2022 à 06:43, Mike Fulton a écrit : > > Hi, > > I am starting to port bison to z/OS and am curious about the best way to go > about debugging. When I go to run ‘bison’ on the sample rpcalc program, e.g. > > Echo “4 9 +” | make run > > it is getting killed due to stack

Re: Language Versions

Hi, > Le 11 juin 2022 à 00:52, slipbits a écrit : > > Could you specify the language version of the generated parser code? This > will help in specifying the correct compiler to use for the generated parser > source code and headers. You mean that we should specify that C++ means C++98, C

Re: lr.type option proposes lr(0) but says option is invalid.

Hi Simon, > Le 28 févr. 2022 à 20:28, Simon Scatton a écrit : > > Hello, > > I've been experiencing with bison's lr.type option yesterday and I found > a strange thing. > > When changing the lr.type option in my bison file I made a typo and I > encountered this error message : > >

Re: glr2.cc compile errors under Windows

Jot, > Le 22 nov. 2021 à 01:42, Jot Dot a écrit : > > For %merge, what is the status where we discussed the possibility of putting > the merge routine(s) as member functions of the generated parser class? That > would indeed simplify my code for merges. I had forgotten about that. Thanks

Re: glr2.cc compile errors under Windows

> Le 21 nov. 2021 à 20:01, Jot Dot a écrit : > > 1>D:\data\c\gen\Gen Parser\parser.cpp(987,42): warning C4003: not enough > arguments for function-like macro invocation 'max' > 1>D:\data\c\gen\Gen Parser\parser.cpp(987,42): error C2589: '(': illegal > token on right side of '::' > > And

Re: glr2.cc compile errors under Windows

> Le 21 nov. 2021 à 15:21, Jot Dot a écrit : > >>> "You need to compile with the /Zc:__cplusplus switch to see the updated >>> value >>> of the __cplusplus macro. We tried updating the macro by default and >>> discovered >>> that a lot of code doesn’t compile correctly when we change the

Re: glr2.cc compile errors under Windows

Jot, > Le 21 nov. 2021 à 13:02, Jot Dot a écrit : > >> 53 #if defined __cplusplus >> 54 # define YY_CPLUSPLUS __cplusplus >> 55 #else >> 56 # define YY_CPLUSPLUS 199711L >> 57 #endif >> >> Please check why your compiler does not define __cplusplus. Compliant >> compilers >> must

Re: glr2.cc compile errors under Windows

Jot, > Le 20 nov. 2021 à 15:57, Jot Dot a écrit : > > Hi Akim, > >> Could you please attach that parser.h file? Or a link to it? Or at least >> the >> relevant excerpts, so that we can have a look at what confuses it. >> >> Did you make sure it compiled in C++11? Actually I would even

Re: glr2.cc compile errors under Windows

Hi Jot, > Le 15 nov. 2021 à 06:13, Jot Dot a écrit : > > I installed the 64 bit version of cygwin and installed flex/bison thru their > setup interface. The flex/bison versions are: > > flex 2.6.4 > bison (GNU Bison) 3.8.2 Great! > I then compile the generated code but I get multiple errors

Re: can i rewrite yyparse() based on ACTION and GOTO tables extracted from XML output?

Hi Levin, > Le 28 oct. 2021 à 08:24, elite liu a écrit : > > Dear Akim, > >I am writing a utility that convert a table-driven dfa into > condition/if-else form, for example: > [...] I have always wondered if code won't be more efficient than tables. Since compiler and cpu have learned

Re: can i rewrite yyparse() based on ACTION and GOTO tables extracted from XML output?

Hi Levin, > Le 14 oct. 2021 à 12:30, elite liu a écrit : > > Hi Guys: > > Because of customization necessaries, i want to rewrite yyparse() based on > ACTION and GOTO tables -- a more straightforward way, just like the classic > compiler book does, and ignore error recovery. > bison is more

Re: Getting a Counter

Hi, > Le 1 oct. 2021 à 07:16, Guenther Sohler a écrit : > > Hi, > In my parser i don't want flex to return comments in my code as flex tokens. > Instead i want to store them in a different list together with their > position. > > Lateron i am using their position to included them in the code

Re: Syntax error messages

Hi Hans, > Le 27 sept. 2021 à 20:54, Hans Åberg a écrit : > > In order to generate better syntax error messages writing out the input line > with the error and a line with a marker underneath, I thought of checking how > Bison does it, but I could not find the place in its sources.

Re: C2026 error in VC++ with large number of tokens

-3.7.90.8-8556.tar.gz https://www.lrde.epita.fr/~akim/private/bison/bison-3.7.90.8-8556.tar.lz https://www.lrde.epita.fr/~akim/private/bison/bison-3.7.90.8-8556.tar.xz Cheers! commit 8556eb4a9a3af10f232f48b05b7b1fe159ffc971 Author: Akim Demaille Date: Sun Aug 29 09:45:24

Re: C2026 error in VC++ with large number of tokens

Hi Vince, > Le 22 août 2021 à 22:14, Vince Huffaker a écrit : > > That macro doesn't seem to exist, but the _MSC_VER does, so this line: > > #ifndef _MSC_VER > > fixes the issue. Yes, of course, sorry about that... >> Also, do you really need to specify the numbers for all the

Re: C2026 error in VC++ with large number of tokens

Hi Vince, > Le 22 août 2021 à 03:58, Vince Huffaker a écrit : > > Hi, > > Thank you for your reply. See the input file, ApReadBinary.ypp (I have > reduced it greatly from the original). The HPP file has the bad line at line > # 3900 - the YY_ASSERT is too long. But line 3900 is no long, if

Re: C2026 error in VC++ with large number of tokens

Hi Vince, > Le 20 août 2021 à 21:39, Vince Huffaker a écrit : > > Hi, > > I know this has been a known bug, but it says that it is fixed, and we just > installed the latest bison, 3.7.6 (from cygwin). We are building a YPP file > and getting this error on a YY_ASSERT line that has lots of

Re: %merge confusion

Hi all, > Le 27 déc. 2020 à 17:03, Akim Demaille a écrit : > > Your problem follows from the fact that there is support for "typed" mergers. > > FWIW, I was unaware of this feature (the fact that the merge functions are > "typed"). This is undocum

Re: [License]Is Bison exception only valid on Bison 2.2?

Hi Kuohong, > Le 17 juil. 2021 à 07:33, Kuo-Hong Wang a écrit : > > Dear all, > Bison is a useful tool! Thanks! > I have one question about the license of generated files by Bison. > > It shows GPL exception with bison as following. Is the exception only > valid on Bison 2.2? or still valid

Re: Am I misunderstanding precedence?

Hi Justin, > Le 14 juin 2021 à 07:02, Justin Ng a écrit : > > I've encountered something which confuses me, but I'm not sure if it's a bug > or just something I don't understand. > > I'm looking at this file, >

Re: undefined symbol for the c++ parser::error() function

Hi Scott, > Le 3 juin 2021 à 00:13, Scott Lorberbaum a écrit : > > My namespace is ucc; > I've named the parser uccParser; > > > This function below I find in the generated ucc.tab.cpp file > void > uccParser::error (const syntax_error& yyexc) > { >error (yyexc.location, yyexc.what

Re: c++ bison, flex, having yylex return parser::symbol_type and take in arguments (parser::semantic_type, parser::location_type)

Hi Scott, > Le 7 mai 2021 à 21:26, Scott Lorberbaum a écrit : > > [...] > i've played around with having the param turned on and either full %param, > or %lex %parse specific. I've turned on and off token.raw and > token.constructor but it doesn't seem to work. > the translate_ function still

Re: Parsing '\x00' -- appears to be the only thing preventing parsing binary data

Hi all, >> On 4/1/21 16:28, Stephen Taylor via Users list for the GNU Bison parser >> generator wrote: >>> Thanks, that seems to get around \x00 -- unfortunately, the same issue then >>> reappears with the values \x80 - \xff … I could special case every single >>> value e.g. >>> \x00 {return

Re: Transitioning C parser to C++

Hi Dave, > Le 8 mars 2021 à 18:29, Dave Abrahams via Users list for the GNU Bison parser > generator a écrit : > > On Sun, Mar 7, 2021 at 8:58 PM Akim Demaille wrote: > >> It would certainly be interesting, thanks for the offer! As a matter of >> fact, if you have

Re: Transitioning C parser to C++

Hi Dave, > Le 7 mars 2021 à 19:43, Dave Abrahams via Users list for the GNU Bison parser > generator a écrit : > > Hi, > > I've been updating a C-based parser to use some of the more-typesafe C++ > constructs, and run into several obstacles / things that were unclear. I was unaware you were

Re: Possible to declare move constructor of basic_symbol as noexcept?

Christian, > Le 30 janv. 2021 à 20:14, Christian Schoenebeck a > écrit : > > On Samstag, 30. Januar 2021 18:10:32 CET Akim Demaille wrote: > >>> Le 19 janv. 2021 à 13:36, Christian Schoenebeck >>> a écrit : >>> >>> that should be >&

Re: Possible to declare move constructor of basic_symbol as noexcept?

Hi Christian, I don't know how I managed to not see your answer about this, but I just discovered it, when I was about to ask for more feedback... > Le 19 janv. 2021 à 13:36, Christian Schoenebeck a > écrit : >> diff --git a/data/skeletons/c++.m4 b/data/skeletons/c++.m4 >> index

Re: Unused attribute for used variable

Hi Christoph, > Le 26 janv. 2021 à 20:10, Christoph Grüninger a écrit : > > Dear Bisons! > > I am still giving CMake's Bison code some love. I regenerated the code > using Bison 3.7.4. But Clang 11 with manually set > -Wused-but-marked-unused warns: > >> [ 56%] Building CXX object >>

Re: ‘void free(void*)’ called on unallocated object ‘yyssa’ [-Wfree-nonheap-object]

Hi Christoph, > Le 19 janv. 2021 à 08:27, Christoph Grüninger a écrit : >> 3. I removed the lines 1717 and 1745 as the label yyerrlab1 must be defined. >> Could you please clarify what you are doing here, and why? > > The lines contained an #if 0 / #endif that hid the label "yyerrlab1:" from

Re: Possible to declare move constructor of basic_symbol as noexcept?

you see a nice way to address this portability issue, please state it. The logs of the CI for this commit are here: https://travis-ci.org/github/akimd/bison/builds/755133452 Cheers! commit a7d1aa221efad101d82817345361647fd02a215c Author: Akim Demaille Date: Mon Jan 18 08:03:44 2021 +0100 c+

Re: ‘void free(void*)’ called on unallocated object ‘yyssa’ [-Wfree-nonheap-object]

Christoph, FWIW, it appears that Bison is vastly underused in this grammar. For instance, all these occurrences of $ should just read $$ or $1. Who is in charge of maintaining the parsers in there? Start: GoalWithOptionalBackSlash { $$ = 0; yyGetParser->SetResult($1); }

Re: ‘void free(void*)’ called on unallocated object ‘yyssa’ [-Wfree-nonheap-object]

[Paul, at the bottom of this message we have a warning from GCC11 that I guess you already had to keep quiet.] Hi Christoph, > Le 18 janv. 2021 à 22:01, Christoph Grüninger a écrit : > > Dear Bison community, > while compiling CMake using GCC 11 (not yet released), I came across several >

Re: Reporting malloc failure in actions

Hi Joe, > Le 30 déc. 2020 à 07:48, Akim Demaille a écrit : > > I don't think this area (yyexhaustedlab) would change, but you are right > it is an internal detail. I'll add something public in the future, > maybe YYNOMEM. Any idea of a good spelling for such a macro? > Y

Re: %merge confusion

Jot, Sorry for not answering faster. I don't have enough time :( I hope that meanwhile you managed to get your project move forward. > Le 1 janv. 2021 à 23:32, Jot Dot a écrit : > >>> The incoming arguments are ok but there is no parsing context provided. >>> It would be (to me) a quite

Re: GLR causing warning about _Noreturn in C99

> Le 14 janv. 2021 à 00:10, Joe Nelson a écrit : > > Akim Demaille wrote: >> I adjusted this patch for Bison. Could you please try this tarball >> before I install the appended patch into master? Thanks in advance. > > Build the version from source, and us

Re: GLR causing warning about _Noreturn in C99

private/bison/bison-3.7.4.256-1c00e.tar.lz https://www.lrde.epita.fr/~akim/private/bison/bison-3.7.4.256-1c00e.tar.xz commit e70df34a35e2548d76ee0ab3f548ccb45fcc3253 Author: Akim Demaille Date: Tue Jan 12 06:28:13 2021 +0100 c: adjust _Noreturn to pedantic clang Reported by Joe Nels

Re: Possible to declare move constructor of basic_symbol as noexcept?

Hi Adrian, > Le 6 janv. 2021 à 20:43, Adrian a écrit : > > Hello, > > Is there any possibility we can declare the move constructor of > basic_symbol as noexcept (if the semantic_types are noexcept > moveable)? > > I have a semantic value that is non-copyable (moveable only) and I > want an

Re: %merge confusion

Hi Jot, > Le 1 janv. 2021 à 23:32, Jot Dot a écrit : > > But, in my defence: >*** >*** That wasn't what I was asking for all this time *** >*** Ok :) >> The

Re: Tokens to patterns?

Hi Maury, > Le 3 janv. 2021 à 15:55, Maury Markowitz a écrit : > > Second: I'm not sure how to answer your question directly, but it seems to > open a larger brain-dump I've been meaning to post. Is this the right forum > to discuss the future of bison, or bison-like systems? It is. However

Re: GLR causing warning about _Noreturn in C99

Hi Joe, Thanks for the report. > Le 3 janv. 2021 à 19:23, Joe Nelson a écrit : > > When I enable %glr-parser, it generates two functions marked with > _Noreturn: > > _Noreturn static void > yyFail (yyGLRStack* yystackp, void *scanner, const char* yymsg) > > _Noreturn static

Re: %merge confusion

Jot, > Le 30 déc. 2020 à 10:18, Jot Dot a écrit : > >>> I get the same yyuserMerge as before. This time, it is using >>> the new type of the rule that the merge is in (%type rule) >>> >>> case 1: yy0->index = stmtMerge (*yy0, *yy1); break; >> >> Which is good. That is what is expected. > >

Re: Tokens to patterns?

Hi Christian, > Le 31 déc. 2020 à 14:27, Christian Schoenebeck a > écrit : > > That even seems to work in combination with type specifiers and string > literals: Yes, and that's documented and stable. > %token ONE "one" > %token TWO "two" > %token THREE "three" > > -> > > %token ONE

Re: Reporting malloc failure in actions

Hi Joe, > Le 29 déc. 2020 à 05:37, Joe Nelson a écrit : > > Hi, is there a recommended way to fail parsing when an action cannot > allocate memory? I could use YYABORT, but the caller could mistake this > for a problem in the input, when it's really an internal problem. I never though about

Re: %merge confusion

Hi Jot, > Le 28 déc. 2020 à 10:09, Jot Dot a écrit : > > I'm not trying to irritate you with all of this. I'm sure you are not. > Alright. I took out the 'api.value.type union' and put in: > %union { > gen::index_t index; > merge_t merge; // A struct to hold my merge info > } > >

Re: %merge confusion

Jot, > Le 27 déc. 2020 à 22:31, Jot Dot a écrit : > > BTW: I'm using: Bison 3.7.1 > >>> Assuming I have something simple like the following: >>> %token IDENTIFIER >>> %type subrule expr >> >> Which means that you are probably using "api.value.type variant". Which does > > *Sigh* > That's

Re: %merge confusion

Jot, > Le 25 déc. 2020 à 04:28, Jot Dot a écrit : > > This is the resultant code generated by bison: > > static void > yyuserMerge (int yyn, YYSTYPE* yy0, YYSTYPE* yy1) > { > YYUSE (yy0); > YYUSE (yy1); > > switch (yyn) >{ > case 1: yy0->gen::index_t = stmtMerge (*yy0, *yy1); break;

Re: %merge confusion

Hi Jot, > Le 25 déc. 2020 à 04:28, Jot Dot a écrit : > > I'm using %glr-parser and ran into a snag with the %merge feature. > > I figure I must be misinterpreting something along the way. > I think I've done what the docs say: >

Re: glr parser and getting semantic values from the lexer

> Le 20 déc. 2020 à 21:55, Jot Dot a écrit : > > I feel real dumb asking this but, > > How do you pass values back from the lexer when using %glr-parser? First of all, you need to understand that when you are in nondeterministic mode, the actions are delayed, the scanner and the parser are

Re: Meson build definition

Hi Daniele, > Le 19 déc. 2020 à 20:17, Daniele Nicolodi a écrit : > > Hello, > > I am working on a project that uses Bison to generate a parser and Meson > as build system. I would like to include Bison as a subproject [1] in > particular to make it easier for folks to hack on the project on

Re: confusing bison error

Hi John, > Le 28 nov. 2020 à 11:27, John P. Hartmann a écrit : > > His goof was to specify '=' (three characters) in flex. So the = token never > got to the parser. Doh... I didn't see it :( Thanks for the resolution of the mystery :)

Re: confusing bison error

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 full trace? Also, have you tried to enable the >> Flex traces, just in case. > > My input string is "CONST\n\trange = 1..10;\n"

Re: confusing bison error

Hi Jot, > Le 27 nov. 2020 à 01:11, Jot Dot a écrit : > > FWIW: I'm new to flex/bison (lex/yacc) but I understand the basic concepts. > win_flex 2.6.4 > bison (GNU Bison) 3.7.1 I'd prefer that you use the most recent release, although it shouldn't make any difference here. > Having said

Re: Debugging "$4"

Maury, > Le 8 oct. 2020 à 15:42, Maury Markowitz a écrit : > >> On Oct 8, 2020, at 2:17 AM, Akim Demaille wrote: >> Chris might be very right here. Maury, have you looked at your debug >> traces? >> https://www.gnu.org/software/bison/manual/html_node/Tracing

Re: Debugging "$4"

Hi Hans, > Le 8 oct. 2020 à 18:06, Hans Åberg a écrit : > > When you compile, did you get a shift/reduce conflict? —I recall Bison > chooses the reduce over shift. Nope, in unresolved S/R conflicts, shifts win. That's what you want for if-then-else.

Re: Debugging "$4"

> Le 7 oct. 2020 à 23:52, Chris verBurg a écrit : > > > I don’t know if this is helpful, but is there a problem with ambiguity > between these parses: > > (IF 1=1 THEN PRINT “3” ) : PRINT “4” > > and > > IF 1=1 THEN (PRINT “3” : PRINT “4”) > > ? Because if the shift/reduce conflict

Re: Question about token stack

Hi Ervin, > Le 30 août 2020 à 20:21, Hegedüs Ervin a écrit : > > oh my... thanks, now it's clear. > > Here is the result: > > Starting parse > [...] > Entering state 1 > Stack now 0 1 > Reading a token > Next token is token T_CONFIG_DIRECTIVE_ARGUMENT () > Parse error: syntax error in file

Re: Question about token stack

> Le 30 août 2020 à 18:06, Ervin Hegedüs a écrit : > > the documentation shows: > > https://www.gnu.org/software/bison/manual/html_node/Enabling-Traces.html > > the option -t (POSIX Yacc compliant) > > the option --debug (Bison extension) Have a look at Bison's examples (e.g.

Re: Question about token stack

> Le 30 août 2020 à 17:17, Ervin Hegedüs a écrit : > > in my parser code I got: > > #ifdef YYDEBUG > yydebug = 1; > #endif > > and I compiled the code: > bison -d myparser.y > flex -d mylexer.l > gcc ... > > the output is: > > --accepting rule at line 52 ("ConfKey2") > --accepting rule

Re: Question about token stack

> Le 30 août 2020 à 16:36, Ervin Hegedüs a écrit : > > I just put: > > %destructor { printf("free() called\n"); free ($$); } <*> > > but it never called, and valgrind still shows that the block is > still reachable. You should add debug traces and study them. Pay special attention to the

Re: Question about token stack

Hi Ervin, > Le 30 août 2020 à 11:44, Ervin Hegedüs a écrit : > > Hi all, > > and in parser: > > https://github.com/airween/flextest/blob/master/myparser.y#L52 > > config_directive_line: > T_CONFIG_DIRECTIVE T_CONFIG_DIRECTIVE_ARGUMENT { printf("'%s' '%s'\n", > $1, $2); free($1);

Re: api.prefix history

ry [0] gives no relevant change history for this > option beyond its introduction in 2.6. Could the change I’ve described be > added to the historical description? Sure. Done. Cheers. commit 0522047c96e18361b62a42da3a15817959483cbd Author: Akim Demaille Date: Sun Aug 30 09:29:0

Re: Parsing a language with optional spaces

Hi Christian, > Le 20 juil. 2020 à 14:51, Christian Schoenebeck a > écrit : > > On Samstag, 18. Juli 2020 08:47:07 CEST Akim Demaille wrote: >>> Le 14 juil. 2020 à 13:31, Christian Schoenebeck >>> a écrit : >>> >>> On Montag,

Re: DOM parsing in bison (was: Parsing a language with optional spaces)

Hi Adrian, > Le 18 juil. 2020 à 10:26, Adrian Vogelsgesang a > écrit : > > Hi Akim, hi Christian, > > Really interesting thread and discussion! > I almost feel guilty for only picking up one particular point ;) > > Akim's comment >> No, it's also about the targeted model. Most other GLR

Re: Parsing a language with optional spaces

> Le 14 juil. 2020 à 13:31, Christian Schoenebeck a > écrit : > > On Montag, 13. Juli 2020 07:56:57 CEST Akim Demaille wrote: > > For the 'married' parser, in the form imagined by me, there would be no > lookahead token, as a lookahead token implies a context-unaware

Re: Parsing a language with optional spaces

Hi Christian, > Le 14 juil. 2020 à 13:44, Christian Schoenebeck a > écrit : > >> -Except for GLR parsers (@pxref{Compiler Requirements for GLR}), the C >> -code that Bison generates requires only C89 or later. However, Bison >> -itself requires common C99 features such as declarations after

Re: Parsing a language with optional spaces

Hi Christian, > Le 13 juil. 2020 à 07:56, Akim Demaille a écrit : > >> Le 12 juil. 2020 à 19:47, Christian Schoenebeck >> a écrit : >> >> And BTW: >> >>> The GLR parsers require a compiler for ISO C89 or later. >> >> Tough requiremen

Re: Parsing a language with optional spaces

> Le 12 juil. 2020 à 19:47, Christian Schoenebeck a > écrit : > >> Additionally,the programmer must fully understand how >> and when the parser handles tokens, otherwise subtle bugsmay be introduced. > > I don't see what they exactly had in mind here for that to claim. Bison is "lazy" wrt

Re: Parsing a language with optional spaces

Hi Daniele, > Le 9 juil. 2020 à 00:25, Daniele Nicolodi a écrit : > >> But the profits would be stunning: you could write parsers in a very >> straight- >> forward way, even for very complex languages. And on the other side it would >> eventually allow to design languages in a much more user

Re: Parsing a language with optional spaces

> Le 8 juil. 2020 à 22:14, Akim Demaille a écrit : > > That reminds me of a paper I read long ago, someone proposing > "heisentokens": having the scanner return multiple tokens concurrently, > for the different scanning options, branched into GLR to follow the >

Re: Parsing a language with optional spaces

> Le 6 juil. 2020 à 22:17, Christian Schoenebeck a > écrit : > > Ok, no idea where one can see the original code (if public at all). I just > found this: > > http://newton.freehostia.com/hp/bas/TREKPT.txt There are some most beautiful BASIC idioms in there. I love this: 5245 LET

Re: Parsing a language with optional spaces

Hi Christian, > Le 8 juil. 2020 à 12:15, Christian Schoenebeck a > écrit : > > On Mittwoch, 8. Juli 2020 06:24:13 CEST Akim Demaille wrote: >> I still think you can address this case with Flex, but I agree it's >> going to be painful. I would go for something like >

Re: Parsing a language with optional spaces

Hi John, > Le 7 juil. 2020 à 10:55, John P. Hartmann a écrit : > > 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. Actually the message you are quoting was really just an

Re: Parsing a language with optional spaces

> Le 6 juil. 2020 à 22:01, Maury Markowitz a écrit : > >> On Jul 6, 2020, at 3:23 PM, Akim Demaille wrote: >> >> FOR/{sp}{id}{sp}={sp}{num}{sp}TO{sp}{num} { printf("for: %s\n", yytext); } > > This is a very different style than what I have seen in

Re: Parsing a language with optional spaces

Hi Maury, > Le 6 juil. 2020 à 18:25, Maury Markowitz a écrit : > > Moving to a new thread - I was surprised I could even post, previous efforts > were bounced from the list server for no obvious reason. That's really weird. >> On Jul 6, 2020, at 9:04 AM, Christian Schoenebeck >> wrote: >>

Re: Which lexer do people use?

> Le 6 juil. 2020 à 14:00, Maury Markowitz a écrit : > >> On Jul 4, 2020, at 6:46 AM, Christian Schoenebeck >> wrote: >> The only thing that people are missing once in a while on scanner side is >> unicode support > > I am missing the capability to support grammars with optional spaces

Re: Which lexer do people use?

Hi Christian, > Le 4 juil. 2020 à 12:46, Christian Schoenebeck a > écrit : > > On Samstag, 4. Juli 2020 08:14:46 CEST Akim Demaille wrote: > > For me, the exaggerated 'divide and conquer' philosophy applied decades ago > by > splitting scanner and parser was a mu

Re: Which lexer do people use?

Hi John, > Le 4 juil. 2020 à 17:02, John P. Hartmann a écrit : > > 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

Re: Which lexer do people use?

Hi Adrian, > Le 4 juil. 2020 à 21:30, Adrian Vogelsgesang a > écrit : > > Also, it allowed us to embed a few hacks directly inside the scanner: E.g. in > a few places our grammar is not actually LR1. Only in very few edge cases, > though, so that we don’t want to use GLR. Hence, our scanner

Re: Which lexer do people use?

Hi Daniele, > Le 3 juil. 2020 à 23:15, Daniele Nicolodi a écrit : > > Hello, > > the historical pairing is using Flex with Bison. However, while Bison is > under active development and seems to be a very solid code base, there > isn't much activity on the Flex side

Re: Bison 3.6 requires runtime type information?

Adrian, > Le 27 juin 2020 à 13:39, Adrian a écrit : > > Hi Akim, > > It would be nice if it were possible to enable parse.assert without rtti, > but I understand if it's difficult/impossible and that it's a very > minor use case. > However, just for discussion, if I understood the docs bison's

Re: Bison 3.6 requires runtime type information?

-fno-rtti to the compiler, indeed. I'll add the commit below to the documentation. Note that I don't think anything changed on this regard since 3.4, the problem might be elsewhere. Cheers! commit 4efb2f7bd27d496e2aacb8867b53f7d22d8dfeda Author: Akim Demaille Date: Sat Jun 27 10:31:59

Re: Redefining the literal string associated to the YYerror symbol

Hi Daniele, > Le 18 juin 2020 à 19:20, Akim Demaille a écrit : > >> However I have a ton of tests that expect the lexer to emit a >> "LEX_ERROR" token on error and I am considering to use YYerror special >> token to report errors instead. Thus the question if I

Re: Token value in custom error reporting

> Le 18 juin 2020 à 20:46, Hans Åberg a écrit : > > Otherwise, in your link above you suggest not using the semantic value in > error messages, but when using locations, it contains the token > delimitations. So there seems to be no advantage letting the lexer generating > the error. It

Re: Token value in custom error reporting

> Le 18 juin 2020 à 19:11, Hans Åberg a écrit : > > >> On 18 Jun 2020, at 18:56, Akim Demaille wrote: >> >>> Le 18 juin 2020 à 14:54, Hans Åberg a écrit : >>> >>> In my C++ parser, the lexer has rule >>> . { return my_pars

Re: Redefining the literal string associated to the YYerror symbol

Hi Daniele, > Le 18 juin 2020 à 10:35, Daniele Nicolodi a écrit : > > On 18/06/2020 00:44, Akim Demaille wrote: >> There is no way to rename it, and it wouldn't make sense as the error >> token is never presented as an "expected token". The error token n

Re: Regarding building bison-3.4.2 on Windows

> Le 18 juin 2020 à 13:35, Singh, Binay a écrit : > > Thanks for your suggestion for newer version. > > If I build it on POSIX / Linux system , will that be compatible to windows ? I think that's the whole point of the POSIX subsystem. But I'm not a Windows user, I just don't know. > My

Re: Token value in custom error reporting

> Le 18 juin 2020 à 14:54, Hans Åberg a écrit : > > In my C++ parser, the lexer has rule > . { return my_parser::token::token_error; } > > When it is triggers, I get the error: > :21.1: error: syntax error, unexpected token error > > It might be nicer to actually write out this

Re: Token value in custom error reporting

Hi Adrian, > Le 18 juin 2020 à 11:26, Adrian Vogelsgesang a > écrit : > > Hi Akim, hi Daniele, > > It would probably help, if the error message would include something like >> Hint: Did you mean to refer to table "MyTable" instead of the string-literal >> 'MyTable'? >> If so, use

Re: Token value in custom error reporting

Daniele, > Le 18 juin 2020 à 10:24, Daniele Nicolodi a écrit : > >> Would you have an example of what you mean? > > Sure, but it is rather contrived :-) > > I am working on a project that is based on Flex and Bison 3.4. The code > goes through some contortions so that the lexer can report

Re: Redefining the literal string associated to the YYerror symbol

Daniele, > Le 18 juin 2020 à 07:57, Daniele Nicolodi a écrit : > > Hello, > > in Bison 3.6 is it possible to redefine the literal string associated to > the YYerror symbol (and to the YYEOF, YYUNDEF ones, although I don't > have immediate need for this)? YYerror is exactly the error token,

Re: Token value in custom error reporting

> Le 18 juin 2020 à 07:49, Daniele Nicolodi a écrit : > > Hi Akim, > > On 17/06/2020 23:43, Akim Demaille wrote: >> I think it's a mistake to try to use the semantic value in error messages. > > The goal would not be to use the semantic value in the error messa

Re: Token value in custom error reporting

Hi Daniele, > Le 17 juin 2020 à 21:56, Daniele Nicolodi a écrit : > > Hello, > > error reporting has always been a pain point for me in the use of flex > and bison, especially in coordinated error handling between the scanner > and the grammar. I am very happy to see a lot of improvements in

Re: Regarding building bison-3.4.2 on Windows

Hi Binay, > Le 17 juin 2020 à 18:26, Singh, Binay a écrit : > > > Hi Support team , > > > I am trying to build GNU bison-3.4.2 The current version is 3.6.4, there's not much point in trying to build 3.4.2. > on Windows / Visual studio 15 . I am not able to find any info in Readme or >

Re: Updating a legacy bison/yacc grammar file (HELP!)

Hi Aryeh, > Le 16 juin 2020 à 20:16, Aryeh Friedman a écrit : > > > That helped significantly but I still have a few more errors on linking now > that compiling is done: > > c++ -v -o unspecified/bin/fmtgen -rdynamic -g -L/usr/local/lib > unspecified/fmtgen/parse.yacc.o

Re: Updating a legacy bison/yacc grammar file (HELP!)

Hi Aryeh, > Le 14 juin 2020 à 17:22, Aryeh Friedman a écrit : > > In attempting to update a previously working (pre-3.6) set of .y's I am now > getting an error that makes no sense to me (I am not the original author) > and all attempts to fix it fail. If you can provide us with a link to the

  1   2   3   4   5   >