Re: example of GNU bison parser with lexer implemented in a C++ class

> On 17 Mar 2025, at 18:22, Basile Starynkevitch > wrote: > > Hello all, > > In the RefPerSys open source inference engine project (the GPL source code is > on > https://github.com/RefPerSys/RefPerSys/ ...) we have a C++ class implementing > lexing. More precisely there is a C++ common super

Re: Unquoted strings in BASIC

> On 3 Dec 2024, at 21:24, James K. Lowden wrote: > > 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. >

Re: Unquoted strings in BASIC

> On 3 Dec 2024, at 17:44, Maury Markowitz wrote: > >> On Dec 1, 2024, at 2:07 PM, James K. Lowden wrote: >> >> require some real thinking, never easy. For example, is >> >> 10100 DATA "one",2B,"three" >> >> valid? If it is, you'll need one pattern for "leading alpha" that might >> be jus

Re: Unquoted strings in BASIC

> On 2 Dec 2024, at 03:10, Maury Markowitz wrote: > > I had managed to get to this point for testing the conditional states: > > [^0-9][A-Za-z]*[,:\n] { > yytext[strlen(yytext) - 1] = '\0'; > yylval.s = str_new(yytext + 1); > return STRING; > } Notice tha

Re: Unquoted strings in BASIC

> On 1 Dec 2024, at 20:07, James K. Lowden wrote: > > 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 > c

Re: Unquoted strings in BASIC

> On 1 Dec 2024, at 19:08, Maury Markowitz wrote: > >> This will probably require you to take into account the current context; see >> Hans's reply. > > Yeah, I am completely new to that side of things. I'm in the bison dox now > and I can't say I'm understanding much yet. Check the Flex ma

Re: Unquoted strings in BASIC

> On 1 Dec 2024, at 16:07, Maury Markowitz wrote: > > But many dialects allow strings to be unquoted as long as they do not contain > a line end, colon or comma: > > DATA 10,20,HELLO,WORLD! One way is to use context switches; see the Flex and Bison manuals. In the .l file one has say: %x D

Re: building a modified GNU bison on Debian

> On 18 Oct 2024, at 10:19, Basile STARYNKEVITCH > wrote: > > …I git cloned GNU bison to > https://github.com/bstarynk/misc-basile/tree/master/bison-refpersys > > Perhaps I was wrong in copying it in some existing repository > https://github.com/bstarynk/misc-basile ? If that is the case pl

Re: Is there a Bison IRC channel?

> On Dec 5, 2023, at 03:16, Steve Litt wrote: > > Is there a Bison IRC channel? Is there a Flex IRC channel? You might try the Usenet newsgroup comp.compilers.

Re: yytname woes

> On Nov 12, 2023, at 18:18, James K. Lowden wrote: > > 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 &g

Re: yytname woes

> On Nov 12, 2023, at 02:23, James K. Lowden wrote: > > My yytname array is obviously messed up. Whether or not it's needed by > the parser, whether or not ASCII characters can be used as tokens, is > immaterial. > > Let's start, shall we, with "is it a bug"? The parser knows how to tran

Re: yytname woes

> 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. Yes, and it is not needed in the actual parser. It is used to print error messages, but one can also

Re: yytname woes

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 "NOT". But when I look up #900, NE, I > get "'<'" because that's the next element in yytname (900 - 255). In Bison, bein

Re: Online yacc/lex grammar editor/tester

> On 7 Sep 2023, at 19:01, Domingo Alvarez Duarte wrote: > > I already know about that grammar and it's already there as "Cxx parser (not > working)" because it uses "error" and auxiliary code to parse "C++" and the > parser I'm using right now doesn't support "error" and at first it's mostly

Re: Online yacc/lex grammar editor/tester

> On 7 Sep 2023, at 15:56, Domingo Alvarez Duarte wrote: > > I'm trying to build an online yacc/lex (LALR(1)) grammar editor/tester to > help develop/debug/document grammars the main repository is here > https://github.com/mingodad/parsertl-playground and the online playground > with several

Re: Pattern matches one type of paren but not another

> On 28 May 2023, at 20:12, Maury Markowitz wrote: > > Following, sort of, some advice I received earlier I modified my bison by > adding this: > > open_bracket: > '(' | '['; > close_bracket: > ')' | ']’; You probably do not want to exchange delimiter types, as in "(…]" and "[…)". > And the

Re: What is a Parser Skeleton?

[Please cc the Bison list, as others can follow the issue and tune in if needed.] > On 12 Apr 2023, at 11:18, Johannes Veit wrote: > > Hello and sorry for the long pause and tanks for your explanation!It makes > sense, but I don’t see a proper connection to the Bison Exception. > In my unders

Re: What is a Parser Skeleton?

> On 23 Feb 2023, at 11:25, Johannes Veit wrote: > > Hello Mr. Åberg and thanks a lot for the explanation. > > I attached a pdf where I (try to) explain the Bison exception. > Could you please verify if it is correct? It is the Bison license exception that is referred to, I believe: Copyrigh

Re: What is a Parser Skeleton?

> On 10 Feb 2023, at 13:52, Johannes Veit wrote: > > "Parser Skeleton" is crucial for understanding the Bison Exception > , but I didn't find a > proper explanation of that term. > > So either: > Where can I find a proper explanation of "

Re: how to solve this reduce/reduce conflict?

> On 22 Sep 2022, at 21:02, Lukas Arsalan wrote: > > On 2022-09-22T15:54:31UTC Hans Åberg wrote: >> Context switches are best avoided unless absolutely necessary, in my >> experience. >> So if one designs ones own language, it might be good to try to avoid them &g

Re: how to solve this reduce/reduce conflict?

> On 22 Sep 2022, at 16:52, Lukas Arsalan wrote: > > On 2022-09-22T07:57:45UTC Hans Åberg wrote: >> On 22 Sep 2022, at 08:30, Lukas Arsalan wrote: >>> [1] -1 --> "num" >>> [2] 1-2 --> "num" "-" "num" >>>

Re: how to solve this reduce/reduce conflict?

> On 22 Sep 2022, at 08:30, Lukas Arsalan wrote: > > Hi, > > At 2022-09-22T07:08:55CEST Akim Demaille wrote: >> This snippet is clearly ambiguous, since it allows two different parses of >> -1, which -Wcex nicely showed. >> > yes. right. > >> If I were you, I would handle this in the scann

Re: Is there a way to have two "cases" with one method?

> On 22 Aug 2022, at 18:12, Maury Markowitz wrote: > > In my BASIC interpreter’s bison code I have one of these: > > CHANGE variable TO variable … > CHANGE is from the original Dartmouth BASIC. It turns out that HP included an > identical feature in their dialect, CONVERT. So I did: … > CON

Re: explain why NOT is missing from generated parser

> On 25 May 2022, at 01:54, James K. Lowden wrote: > > I'm writing a parser for Cobol. The newsgroup comp.compilers FAQ has some info about it, the past posted monthly to the list, but here is a cached version: http://www.faqs.org/faqs/compilers/faq/

Re: [Suspected Spam] Weird Rule Matching

> On 7 Apr 2022, at 16:35, Tom Flux wrote: > > Thanks a lot for the example, that's pretty close to how I modeled my > instructions, I think I'm am just storing them slightly weirdly. > > Think I am finally getting the hang of it... :) Make sure to post replies to the list so that others can

Re: Weird Rule Matching

> On 7 Apr 2022, at 12:00, tom2 wrote: > > I have heard of an AST, and, against my better judgement, thought they were > to complex for my needs and decided to represent the instructions as one long > list, that gets edited by loops/conditionals. > > I see the error of my ways now, but I am

Re: Weird Rule Matching

> On 7 Apr 2022, at 10:14, tom2 wrote: > > It does actually cause an issue because I am rely on the idea that the rule > will be matched before the next if token is found, in order to have nested > conditionals. Typically, one build an AST (abstract syntax/semantic tree) that can be execute

Re: Typescript grammar in Bison

> On 22 Mar 2022, at 21:24, Ricard Gascons wrote: > > I've been a Bison user for some time now, I've been writing some toy > projects here and there. I was wondering if there are online resources I > could find existing grammar from well-known programming languages? Just the > definitions, not

Re: glr2.cc compile errors under Windows

> On 21 Nov 2021, at 13:02, Jot Dot wrote: > >> 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 define it

Re: Syntax error messages

> On 1 Oct 2021, at 23:30, Christian Schoenebeck > wrote: > >> For the purpose of writing out the line in the error messages, this method >> (using C++) did not work out well, because I have two parsers, one for the >> language and one for directives, and it turns out to be difficult to pass

Re: Getting a Counter

> On 1 Oct 2021, at 07:16, Guenther Sohler wrote: > > 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 again.

Re: Syntax error messages

> On 28 Sep 2021, at 14:10, Christian Schoenebeck > wrote: > > On Montag, 27. September 2021 22:07:33 CEST Hans Åberg wrote: >>>> In order to generate better syntax error messages writing out the input >>>> line with the error and a line with a marker un

Re: Syntax error messages

> On 27 Sep 2021, at 22:02, Akim Demaille wrote: > > 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,

Re: Syntax error messages

> On 27 Sep 2021, at 22:02, Akim Demaille wrote: > > 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,

Syntax error messages

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. —Specifically, a suggestion is to tweak YY_INPUT in the lexer to buffer one inp

Re: text is not parsed correctly due to shift/reduce conflict

try %glr-parser command - it helps in my case:-) > > сб, 24 июл. 2021 г. в 21:16, Hans Åberg : > > > On 24 Jul 2021, at 16:34, Guenther Sohler wrote: > > > > When trying to code a c language parser I got a issue with shift/reduce > > conflict in bison, which actual

Re: text is not parsed correctly due to shift/reduce conflict

> On 24 Jul 2021, at 16:34, Guenther Sohler wrote: > > When trying to code a c language parser I got a issue with shift/reduce > conflict in bison, which actually hurts me. You might check the LALR(1) grammars for C and C++ others have done. Two examples: https://isocpp.org/wiki/faq/compiler-

Re: Collecting statistics after parsing

> On 4 May 2021, at 20:09, Maury Markowitz wrote: > > Before I reinvent the wheel: I'm wondering if anyone has some boilerplate > code for printing out the frequency of tokens found in the source? The Bison parser calls yylex when getting new tokens, so you might it make it.

Re: Resolving shift/reduce conflicts?

> On 2 Feb 2021, at 07:50, Christoph Grüninger wrote: > > Dear Bisons, > > I have another issue within the CMake parser code. When using the > attached cmDependsJavaParser.y with Bison 3.7.5, i get the following > warning: 4 shift/reduce conflicts [-Wconflicts-sr]. When adding > -Wcounterexamp

Re: Debugging "$4"

> On 9 Oct 2020, at 06:13, Akim Demaille wrote: > > Hi Hans, Hello, >> 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 unreso

Re: Debugging "$4"

> On 7 Oct 2020, at 22:52, Maury Markowitz wrote: > > I have these rules in my BASIC.y: > > statements: > statement > { > $$ = g_list_prepend(NULL, $1); > } > | >statement ':' statements >{ > $$ = g_list_prepend($3, $1); >} >

Re: C preprocessor

> On 13 Aug 2020, at 07:49, Giacinto Cifelli wrote: > > I am wondering if it is possible to interpret a c-preprocessor (the second > preprocessor, not the one expanding trigrams and removing "\\\n") or an m4 > grammar through bison, and in case if it has already been done. > I think this kind

Re: Which lexer do people use?

> On 3 Jul 2020, at 23:15, Daniele Nicolodi wrote: > > Which other scanners do people use? You might ask this question in the Usenet newsgroup comp.compilers.

Re: Token value in custom error reporting

> On 19 Jun 2020, at 07:16, Akim Demaille wrote: > >> 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 >> de

Re: Token value in custom error reporting

> On 18 Jun 2020, at 19:21, Akim Demaille wrote: > >> Le 18 juin 2020 à 19:11, Hans Åberg a écrit : >> >>> On 18 Jun 2020, at 18:56, Akim Demaille wrote: >>> >>> I have already explained what I don't think this is a good idea. >>&g

Re: Token value in custom error reporting

> 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_parser::token::token_error; } >> >> When it is triggers, I get the error: >&

Re: Token value in custom error reporting

> On 18 Jun 2020, at 10:24, Daniele Nicolodi wrote: > > On 18/06/2020 00:39, Akim Demaille wrote: >> >> Would you have an example of what you mean? > … > In the existing code, on error the lexer emits a LEX_ERROR token. This > results in a grammar error that triggers error recovery (good) but

Re: Dynamic tokens

> On 3 Feb 2020, at 16:33, Ervin Hegedüs wrote: … >>> Example from the language: >>> @eq 1 >>> @lt 2 >>> @streq foo >>> >>> The problem is that the LANG_OP_ARGUMENT could be anything - for example, >>> that could be also starts with "@". So, the next expression is valid: >>> >>> @streq @streq

Re: Dynamic tokens

> On 2 Feb 2020, at 20:29, Ervin Hegedüs wrote: > > is there any way to make a parser with "dynamic" tokens? > > I mean in compiling time I don't know the available tokens. It is not possible to have dynamically created token values, … > Now I describe > the necessary token with regex, but I

Re: Further C++ operators for position

> On 5 Nov 2019, at 07:51, Akim Demaille wrote: > >> Le 4 nov. 2019 à 21:16, Hans Åberg a écrit : >> >> >>> On 4 Nov 2019, at 18:12, Akim Demaille wrote: >>> >>>> Le 4 nov. 2019 à 17:03, Matthew Fernandez a >>>> écri

Re: Further C++ operators for position

> On 4 Nov 2019, at 18:12, Akim Demaille wrote: > >> Le 4 nov. 2019 à 17:03, Matthew Fernandez a >> écrit : >> >> The std::less implementation you suggest is to also lexicographically >> compare the filenames themselves? I’m not sure this makes sense, because >> source positions from two d

Re: Further C++ operators for position

> On 4 Nov 2019, at 07:52, Akim Demaille wrote: > >> Le 4 nov. 2019 à 05:27, Matthew Fernandez a >> écrit : >> >> I recently had a use case for comparing source positions coming out of a C++ >> Bison-produced parser. While operator== and operator!= are implemented on >> the position class

Re: [Mesa-dev] Mesa (master): glsl: do not use deprecated bison-keyword

> On 22 May 2019, at 15:41, Hans Åberg wrote: > >> Otherwise we'd need to >> commit the generated files, which is tricky because the location >> depends on where the build-dir is located, and would probably not play >> well with different developers ha

Re: [Mesa-dev] Mesa (master): glsl: do not use deprecated bison-keyword

> On 22 May 2019, at 15:31, Erik Faye-Lund wrote: > > On Wed, 2019-05-22 at 15:21 +0200, Hans Åberg wrote: >> >> One can set the distribution so that the Bison sources are only re- >> compiled if modified. > > This would only work for tarballs, though,

Re: [Mesa-dev] Mesa (master): glsl: do not use deprecated bison-keyword

> On 22 May 2019, at 08:54, Erik Faye-Lund wrote: > > The problem is that Bison doesn't seem to have any mechanism for doing > statements like these conditionally. The only way around that that I > can see is to pre-process the source files somehow. But especially with > three different build s

Re: how to get left hand side symbol in action

> On 10 May 2019, at 07:24, Akim Demaille wrote: > > 1. there is a real and valid need for the feature, which I still need > to be convinced of, especially because symbol names are technical > details! One can also write better error messages by using these internal yytname_ table names:

Re: how to get left hand side symbol in action

> On 10 May 2019, at 07:24, Akim Demaille wrote: > >> In practice you just need the symbol name as is. Nobody needs the >> translation, > > I beg to disagree. Nobody should translate the keyword "break", > but > >> # bison /tmp/foo.y >> /tmp/foo.y:1.7: erreur: erreur de syntaxe, : inattendu

Re: how to get left hand side symbol in action

> On 9 May 2019, at 08:50, Akim Demaille wrote: > >> Le 6 mai 2019 à 22:45, Hans Åberg a écrit : >> >>> On 6 May 2019, at 18:09, Akim Demaille wrote: >>> >>>> Le 6 mai 2019 à 14:50, Hans Åberg a écrit : >>>> >&

Re: Parsing user-defined types

> On 8 May 2019, at 22:30, EML wrote: > > Sometimes, to make the grammar manageable, the lexer has to *dynamically* > return 'typename' instead of 'identifier'. Only semantic analysis can > determine what is a user-defined type (say 'foo'), so the lexer must be told > at runtime that 'foo' is

Re: Parsing user-defined types

> On 8 May 2019, at 19:48, EML wrote: > > I'm having trouble seeing how to handle user-defined types without lots of > feedback from the parser to the lexer. For example, consider a C-like > language with a struct declaration: > > foo() { > struct a {...}; // type defn > struct a b;

Re: how to get left hand side symbol in action

> On 6 May 2019, at 18:09, Akim Demaille wrote: > >> Le 6 mai 2019 à 14:50, Hans Åberg a écrit : >> >> >>> On 6 May 2019, at 11:28, r0ller wrote: >>> >>> Hi All, >>> >>> Is it possible in *any* way to get the left hand s

Re: how to get left hand side symbol in action

> On 6 May 2019, at 15:21, uxio prego wrote: > >> On 6 May 2019, at 14:50, Hans Åberg wrote: >> >>> On 6 May 2019, at 11:28, r0ller wrote: >>> >>> Is it possible in *any* way to get the left hand side symbol in an action >>> of a ru

Re: how to get left hand side symbol in action

> On 6 May 2019, at 11:28, r0ller wrote: > > Hi All, > > Is it possible in *any* way to get the left hand side symbol in an action of > a rule? Say, I have: > > A : B C > { > std:cout<<"left hand side symbol is:"< }; > > I tried to find it out myself and googled a lot but didn't find any

Re: Compilation error in ancient YACC code

[Please keep the cc to the list so that others can follow the issue.] > On 16 Apr 2019, at 01:23, Chris Bragg wrote: > > Hans, > Thanks for the suggestion. It worked and I now have a YACC output file. > Very grateful for your response. Good. ___ he

Re: Compilation error in ancient YACC code

> On 15 Apr 2019, at 22:37, Chris Bragg wrote: > > The YACC compiler generates only two errors. I suspect that the problem is a > minor one and that a small fix to the syntax will fix the problem. I am not > a YACC programmer - it is a complete mystery to me - and I was hoping a > posting of the

Re: simple problem

> On 23 Feb 2019, at 23:19, workbe...@gmx.at wrote: > > Hi again, i have the following code: Here is a slightly different code, for example with input "x1 y2 34 ? exit". The lexer will rescan unless there is an action return, which happens for "exit". Typically in a lexer, whitespace is eate

Re: Not able to use %union?

> On 18 Feb 2019, at 04:37, Peng Yu wrote: > > 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 alloc

Re: Not able to use %union?

> On 18 Feb 2019, at 04:37, Peng Yu wrote: > > 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 alloc

Re: bison info doc - precedence in recursive parsing

> On 18 Feb 2019, at 08:28, Akim Demaille wrote: > >> 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 : >>>> >>>&

Re: How to decide what to put in the lexer and the grammar respectively?

> On 18 Feb 2019, at 06:44, Akim Demaille wrote: > >> 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 >>> t

Re: How to decide what to put in the lexer and the grammar respectively?

> 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

Re: bison info doc - precedence in recursive parsing

> 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

Re: How to decide what to put in the lexer and the grammar respectively?

> 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

Re: bison info doc - precedence in recursive parsing

> 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,

Re: Is it always possible to make a non-reentrant parser reentrant?

> On 12 Feb 2019, at 20:27, Peng Yu wrote: > >> We should probably offer an example of a pull parser in examples/c. >> Have a look at the documentation to have an idea of what I mean. > > OK. I will take a look at it. > > Bash uses one parser to deal with both interactive run and > non-intera

Re: Is it always possible to make a non-reentrant parser reentrant?

> On 9 Feb 2019, at 00:21, Peng Yu wrote: > >> %x INITIAL HEREDOC > > I see %x is from flex. Bash can support nested heredoc. How can it be > implemented in flex? For nested environments one uses a stack, if there are local variables to keep track of. Such switches will then appropriately ha

Re: bison info doc - precedence in recursive parsing

> On 10 Feb 2019, at 11:07, Akim Demaille wrote: > >> Le 10 févr. 2019 à 00:12, Hans Åberg a écrit : >> >>> On 4 Feb 2019, at 07:32, Akim Demaille wrote: >>> >>> Make a full example, feed it to bison with --graph, and look at the >>> re

Re: bison info doc - precedence in recursive parsing

> 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=record feature, for the calc++ example. Might be of help when

Re: bison info doc - precedence in recursive parsing

> On 4 Feb 2019, at 07:32, Akim Demaille wrote: > > Make a full example, feed it to bison with --graph, and look at the resulting > graph. You should understand what is going on (provided you understand how > LR parsers work). According to [1], .gv is preferred as .dot can be confused with

Re: bison info doc - precedence in recursive parsing

> On 5 Feb 2019, at 18:56, Akim Demaille wrote: > >> Le 5 févr. 2019 à 10:28, Hans Åberg a écrit : >> >>> On 5 Feb 2019, at 07:18, Akim Demaille wrote: >>> >>> Yes, on "real life grammars", Dot fails to render anything. And the result

Re: bison info doc - precedence in recursive parsing

> On 5 Feb 2019, at 07:18, Akim Demaille wrote: > >> Le 4 févr. 2019 à 23:50, Hans Åberg a écrit : >> >>> On 4 Feb 2019, at 22:59, Uxio Prego wrote: >>> >>> can’t remember any such graphviz failure, even with graphs >>> so large, the

Re: bison info doc - precedence in recursive parsing

> On 4 Feb 2019, at 22:59, Uxio Prego wrote: > > can’t remember any such graphviz failure, even with graphs > so large, their output isn't actually useful, unless for navigating > with e.g. xdot. > > I however have only used -Tpng, never -Tpdf. Also no -O, but I > guess that’s simply and works

Re: bison info doc - precedence in recursive parsing

> On 4 Feb 2019, at 07:32, Akim Demaille wrote: > > Make a full example, feed it to bison with --graph, and look at the resulting > graph. I could not get an output using 'dot -Tpdf parser.dot -O'. — Perhaps the grammar is too large, small .dot examples work. __

Re: bison info doc - precedence in recursive parsing

> On 3 Feb 2019, at 07:50, an...@aakhare.in wrote: > > The first effect of the precedence declarations is to assign precedence > levels to the terminal symbols declared. The second effect is to assign > precedence levels to certain rules: each rule gets its precedence from the > last terminal

Re: [Question]:Question about bison adding GPL copyright to the parser files generated by bison and yacc.c

> On 26 Jan 2019, at 23:54, Christian Schoenebeck > wrote: > > On Samstag, 26. Januar 2019 22:29:08 CET Hans Åberg wrote: >>> No, that's not what the exception sais. The exception applies (and hence >>> the freedom to distribute a Bison generated parser

Re: [Question]:Question about bison adding GPL copyright to the parser files generated by bison and yacc.c

can be copied to the output file, as multiple copyrights can be applicable, though it is only valid for the part that comes from the skeleton file. Perhaps that should be clarified, too. > On 1/26/19 22:28, Hans Åberg wrote: >> From a legal point of view, copyright applies to the code

Re: [Question]:Question about bison adding GPL copyright to the parser files generated by bison and yacc.c

> On 26 Jan 2019, at 21:48, Christian Schoenebeck > wrote: > > On Samstag, 26. Januar 2019 14:31:06 CET Hans Åberg wrote: >>> On 21 Jan 2019, at 17:24, bird bravo wrote: >>> I noticed that when I use bison and the parser skeleton(yacc.c) to >>> >&g

Re: [Question]:Question about bison adding GPL copyright to the parser files generated by bison and yacc.c

> On 26 Jan 2019, at 21:48, Christian Schoenebeck > wrote: > > On Samstag, 26. Januar 2019 14:31:06 CET Hans Åberg wrote: >>> On 21 Jan 2019, at 17:24, bird bravo wrote: >>> I noticed that when I use bison and the parser skeleton(yacc.c) to >>> >&g

Re: [Question]:Question about bison adding GPL copyright to the parser files generated by bison and yacc.c

> On 21 Jan 2019, at 17:24, bird bravo wrote: > >I noticed that when I use bison and the parser skeleton(yacc.c) to > generate a parser file... there will be a copyright notice to claim the > file is a GPLV3 and an exception declaration... I wanna know is that OK to > use and distribute the

Re: Best Practice: lexer error to silent parser abort

> On 1 Jan 2019, at 23:19, Simon Richter wrote: > > Hi, > > I'm wondering what would be the best way to communicate from the lexer > to the parser that the lexer detected something it could not tokenize > (in my case, characters outside the allowed character set). > > In this case, it is fair

Re: No Bison 3 in untainted macOS installs

> On 21 Dec 2018, at 11:32, Uxio Prego wrote: > > 0. Consider a Yacc parser as a way to have a well > documented common ground for Bison 2 and potential > future releases of Bison departing from Bison 2 but not > departing from Yacc compatibility - simply my own > guess on the Bison roa

Re: No Bison 3 in untainted macOS installs

> On 21 Dec 2018, at 10:00, Uxio Prego wrote: > >> A threaded parser aside, I found threading difficult to debug in general, so >> good with a way to turn it off. > > Not sure what do you mean. Threaded parser to me sounds like a *.y > source code doc where threads are spawned and joined in t

Re: Error with grammar arguments

> On 18 Dec 2018, at 20:06, Rob Casey wrote: > > Yes - That is correct Chris. I am allocating memory within Flex for tokens. > This issue first manifest itself when I started to add code for the proper > freeing on this memory (where no longer required) within grammar actions. It looks like a

Re: No Bison 3 in untainted macOS installs

> On 15 Dec 2018, at 19:31, Uxio Prego wrote: > >> In fact not so difficult. But it might be good to complement with a package >> manager. > > Yes. This is maybe not going to be popular here, but > in the light of the other replies I think the best for me > would be to: > > - Develop a 2 to

Re: No Bison 3 in untainted macOS installs

> On 15 Dec 2018, at 17:58, Uxio Prego wrote: > > >> On 15 Dec 2018, at 17:02, Uxio Prego wrote: >> >>> Also, MacPorts [3] packages tend to be more up-to-date. It is installed in >>> /opt/, so /usr/local doesn't get cluttered. So it is possible to choose >>> what one wants, say GCC from Ma

Re: No Bison 3 in untainted macOS installs

> On 15 Dec 2018, at 17:02, Uxio Prego wrote: > >> Bison installs in /usr/local/ direct from the sources in [1], and works fine >> will their inhouse version of clang. Bison also needs m4 which can be >> installed the same from [2]. Just compile with ./configure && make, and >> 'make pdf' if

Re: No Bison 3 in untainted macOS installs

> On 15 Dec 2018, at 11:05, Uxio Prego wrote: > > Does anybody know when Bison 3 is going to be added to > macOS? > > Fortunately other projects such as Homebrew allow a > straightforward selection of a cutting edge alternative Bison > under `/usr/local/`, however isn't it a bit sad to add Hom

Re: are there user defined infix operators?

> On 10 Nov 2018, at 13:51, Uxio Prego wrote: > > Alright, but OK, let's hear! >> On 8 Nov 2018, at 23:37, Hans Åberg wrote: >> >>> On 8 Nov 2018, at 22:34, Uxio Prego wrote: >>> >>>> [...] >>> >>> The example and

Re: improving error message

> On 10 Nov 2018, at 12:50, Akim Demaille wrote: > >> Le 10 nov. 2018 à 10:38, Hans Åberg a écrit : >> >>> Also, see if using %param does not already >>> give you what you need to pass information from the scanner to the >>> parser’s yyerro

Re: improving error message (was: bison for nlp)

> On 10 Nov 2018, at 09:02, Akim Demaille wrote: > > Hi Hans, Hello Akim, > Yes. Some day we will work on improving error message generation, > there is much demand. One thing I’d like to have is if there is an error with say a identifier, also writing the out the nam

  1   2   >