action code block delimiters
hello bison team
I have studied bison and developed software based on it. My question is one
technical and later one is in general.
After using bison for some reason, I developed parser generator which is
unique in implementation compare to many years parser generators are modeled on
yacc. Parser generator gills which I created is on github
https://github.com/aakhare-anand/gills. In this the skeleton parser is library
and actual auto generated code is just data structure. I am in process of
developing tool to convert yacc like syntax file to the data structure. One
thing I noticed is that if we have proper delimiter for action code blocks like
{# or anything appropriate then we do not need to check for syntax of C in
action code. I am not sure why this has not been simplified for easier
implementation of parser generator. If there is any technical reason that it
did not work out or has this been a discussion earier that did not conclude to
go ahead with it, pls give me some pointers. If proper delimiters are used,
rest of action code block can be left to compiler to compile it.
Another in general question is after I developed the gills, if it needs to
be used by some project, I could not figure out except compilers and
interpreters can use it. I did it not because i am expert and earn through
compiler or parser generator work and so my ideas about applications of parser
generators are limited. Pls provide me any inputs on what software applications
or industries are parser generators used heavily?
Regards
Anand
parser multiple times called recursively
hello,
with pure option, bison parser can be multithreaded. however, i want to
call parser recursively by iitself. Below is small code snippet to exemplify:
token1: token2 token3
{
// switch yylex buffer state
yyparse();
// switch back to previous yylex buffer state
}
In this yylex() is used with buffer state. Will this be fine or is there issue
in this? This is called in single context and no multi threading. yylex() will
have parameter for YYSTYPE. flex code has to be reentrant. This is not multi
threaded though recursively calling parser within itself is something I am not
sure. Pls clarify if this is fine.
Regards
Anand
tokens without input match
in following code, bison matches for word1 and word2 for input but it doesn't bypass word3 while it matches, executes action and throws error. Is it possible that anything that doesn't reach till input can be blocked? input: word1 | word2 word1 : WORD1 word2: WORD2 word3: WORD3 Thank a lot! Anand ___ help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison
ambiguous syntax error
Hi Bison team/users, I have written lot many code around bison parser generated for some work. But, it is throwing error syntax is ambiguous. I was verifying my syntax in sample implementation to confirm if something is wrong. My bison parser code is quite big now. I have been using bison for 2 years now for some work which is not finished yet. Nothing obvious is ambiguous appears. Should I go in exploring .tab.c file which I find difficult to understand. The whole idea to use bison parser is to be able to finish work fast. How much generated parser has to be understood? Regards, Anand ___ help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison
Re: ambiguous syntax error
I am using report option to generate report. I have gone thru the report to find expected conflicts. Odd thing is it is crashing though after ambiguous error it should return. Sent from my iPhone > On 08-Aug-2018, at 7:12 PM, Hans Åberg wrote: > > >> On 8 Aug 2018, at 14:36, Anand Akhare wrote: >> >> I have written lot many code around bison parser generated for some >> work. But, it is throwing error syntax is ambiguous. >> ... >> How much generated parser has to be understood? > > Have you used the option %verbose (or --verbose)? It writes a .output file > that says what the conflict is, and in those rules a dot '.' telling what > tokens causing the problem. > > ___ help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison
Re: ambiguous syntax error
Crash is in parser code. That is why I asked should I explore parser code Sent from my iPhone > On 08-Aug-2018, at 9:16 PM, Hans Åberg wrote: > > >> On 8 Aug 2018, at 16:50, Anand Akhare wrote: >> >> I am using report option to generate report. I have gone thru the report to >> find expected conflicts. Odd thing is it is crashing though after ambiguous >> error it should return. > > Try to run it in a debugger to see where it crashes. > > ___ help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison
YYMAXDEPTH and stack usage
Hi help-bison, stack memory is allocated with size YYMAXDEPTH * sizeof(GLRStackItem) and YYMAXDEPTH defaults is 1. Does this reflect as maximum number of tokens which means maximum number of tokens that can be shifted is 1 without reducing(likely to happen in right recursion)? Regards, Anand ___ help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison
Re: YYMAXDEPTH and stack usage
While left recursion is preferable to avoid high stack consumption, is it theoretically possible to convert every right recursive grammar to left recursive including mutually right recursive? Sent from my iPhone > On 08-Sep-2018, at 5:42 PM, Akim Demaille wrote: > > > >> Le 8 sept. 2018 à 09:14, Akim Demaille a écrit : >> >> >> >>> Le 7 sept. 2018 à 08:13, Anand Akhare a écrit : >>> >>> Hi help-bison, >>>stack memory is allocated with size YYMAXDEPTH * sizeof(GLRStackItem) >>> and YYMAXDEPTH defaults is 1. >>> Does this reflect as maximum number of tokens which means maximum >>> number of tokens that can be shifted is 1 without reducing(likely to >>> happen in right recursion)? >> >> Nope, that’s the LR stack, and the LR stack is composed of both tokens >> _and_ non terminal symbols. That’s really the set of symbols >> (terminal or not) that have been shifted, and waiting to be part > > (I shouldn’t have said ’shifted’ here, I should have written ‘pushed’) > >> of a reduction. >> ___ >> help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison > ___ help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison
odd error messages
Hello, after running parser on code, error messages are showing in wrong sequence. Below are errors with line 379 and 378 in wrong sequence when it should be 378 followed by 379. preprocess.y:379.13-27: error: symbol var_recur_comma is used, but is not defined as a token and has no rules %type var_recur_comma ^^^ preprocess.y:378.13-28: error: symbol var_recur_dollar is used, but is not defined as a token and has no rules %type var_recur_dollar Further, the error is showing for token for which rule is defined in further code. var_recur_comma: COMMA ; There is nothing missing that can generate error. There can be some data point I may not have for this error. There are some more tokens with same problem and some with warnings. Warnings of some tokens still are same but not reported as error. Bison is 3.0.3 compiled from source code tarball. Regards, Anand ___ help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison
Re: odd error messages
Hello Akim, I am still seeing same problem with Bison 3.1. If i try with smaller example it may work unless there is some trigger known that cause the error message. Some tokens are showing error while some are warning and many different are passing fine. If it's only warning, then it is possible to ignore it and get the final code. Is it possible to get parser generated with this error being ignored? Regards, Anand On Sun, Oct 7, 2018 at 11:41 AM Akim Demaille wrote: > Hi Anand, > > > Le 7 oct. 2018 à 05:27, Anand Akhare a écrit : > > > > Hello, > > after running parser on code, error messages are showing in wrong > > sequence. > > Below are errors with line 379 and 378 in wrong sequence when it should > be > > 378 followed by 379. > > Yes, this is a known issue. Not too much of a problem IMHO, > so I don’t plan to fix this soon. It is non trivial: the > errors are reported in the order in which they are discovered, > in different phases. > > > preprocess.y:379.13-27: error: symbol var_recur_comma is used, but is not > > defined as a token and has no rules > > %type var_recur_comma > > ^^^ > > preprocess.y:378.13-28: error: symbol var_recur_dollar is used, but is > not > > defined as a token and has no rules > > %type var_recur_dollar > > > > Further, the error is showing for token for which rule is defined in > > further code. > > var_recur_comma: > > COMMA > > ; > > This is weird. Can you try to find a minimal example that > shows the problem? > > > There is nothing missing that can generate error. > > There can be some data point I may not have for this error. > > There are some more tokens with same problem and some with warnings. > > Warnings of some tokens still are same but not reported as error. > > > > Bison is 3.0.3 compiled from source code tarball. > > Please, try with Bison 3.1. ___ help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison
Re: bison info doc - precedence in recursive parsing
Pasting link of info doc https://www.gnu.org/software/bison/manual/html_node/How-Precedence.html#How-Precedence > On 03-Feb-2019, at 12:20 PM, wrote: > > Hello, > in info doc of bison, it is mentioned that rule gets its precendence from > last terminal symbol. > pasted below: > 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 symbol mentioned in the components. > > For below example, how the parsing will happen if above is the case: > > nonterm1 : nonterm2 > | nonterm1 term1 nonterm3 nonterm4 > | nonterm1 term2 nonterm5 nonterm6 > > One more example: > nonterm1 : nonterm2 nonterm3 > | nonterm1 term1 nonterm2 nonterm3 > | nonterm1 term2 nonterm2 nonterm3 > > Consider first example. First parser will consume nonterm2 then for term1 > rule, nonterm1 will hold nonterm2 value and term2 higher precedence than > term1, parser have to pass value to nonterm1 in term2 rule but it is invalid > if we provide term1 precedence to term1 rule because as the statement > suggests, last terminal token gives rule precedence. Assigning value of > "nonterm3 nonterm4" to nonterm1 in term2 rule is not possible or is it? > Value is for term or nonterm but not partial set of symbols in rule. is it > right? > Does the info doc says last terminal symbol as last but one symbol which if > it is terminal? > > Regards, > Anand ___ help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison
