Re: Help with systemverilog grammar
At 12:06 -0800 2005/02/18, Soumitra Kumar wrote: >I am willing to write a parser for systemverilog. >Following is the LRM. >http://www.eda.org/sv/SystemVerilog_3.1a.pdf > >I am looking for some advice. > >. Should I take the bnf as it is and start resolving >the conflicts, or rewrite the rules myself. This depends on the language. There are two major hurdles: One is that the BNF of languages usually do not tell the whole story, but the language also has some context information that dictates the use of the grammar. For example, the language may admit one to define new symbols. In this case, one would put the new symbols on a lookup table which the lexer reads, and returns the grammar. Another problem is that the lexer always reads just one token ahead, and that the parser that Bison generates is LALR(1), which is a limited set of CFG grammars. Then one can either attempt to rewrite the grammar, sometimes tweak the lexer, or use the GLR. I usually suggest one to be conservative on the last one, because GLR cannot help a faulty grammar. And recurive rules should normally be left recursive (see the Bison manual): A: x | A y so as to prevent the parser stack from growing. >. In case of reduce/reduce conflicts, multiple rules >have the same lookahead symbol. If this non-terminal >is used in multiple rules, it becomes difficult to >identify which rule is the culprit for a particular >lookahead symbol. Is there a way in bison to know this >information. Turn on the --verbose option, to get a .output file with a description of the state machine that Bison generates (which runs the parser). >. Is there a hacking/design document for bison? Akim Demaille posted a bi.pdf in this list: Date: 10 Jan 2002 11:32:03 +0100 List-Archive: <http://lists.gnu.org/pipermail/help-bison> Hans Aberg ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: Forcing multiple parse stacks to 'reduce'
At 17:03 + 2005/02/28, Derek M Jones wrote:
>I have written a parser for C that processes
>a single statement or declaration at a time.
>So after each statement/declaration yyparse
>returns.
Bison is clearly not built to handle such applications. The normal thing is
to handle the whole language in one go. (How do you handle environments,
like "{...}" statement-by-statement?)
>Originally I used various ad-hoc rules in yylex
>to figure out which was the last token of a
>statement/declaration and then returned a zero
>value as the subsequent token.
>
>These ad-hoc rules are complicated (for instance,
>a ; can occur in a for loop header and a { can
>occur in a cast) and I had the 'great' idea of allowing
>the token following the last token of a statement/declaration
>to 'naturally' cause yyparse to generate the outstanding
>reductions. So in:
>
>w=3;
>y=5;
>
>when yylex returns id (because it has encountered y)
>the sequence w=3; reduces to statement and yyparse
>returns (yes, I need to hang onto y in order to correctly
>parse the next statement).
>
>In some cases multiple parse stacks are outstanding,
>and in most cases the following token causes the expected
>return to deterministic parsing and subsequent reduction to
>the accept state. But in some cases it does not. For instance,
>in
>
>typedef x y;
>
>by the time the ; is encountered there are three parse stacks.
>Depending on the token that follows the ; these three parse stacks
>may or may not be reduced to a single stack (which then reduces
>to a declaration).
>
>In the case:
>
>typedef x, y;
>typedef i, j;
>
>the second typedef token is shifted onto all three stacks and
>subsequent tokens are processed like a declaration (which they
>do form part of)! So I don't get a parse of a single declaration
>(in fact yyparse eventually reports an ambiguity).
>
>I know that for some grammars the optimizations performed by
>Bison result in ambiguities being reported (i.e., the BOGUS
>example in 5.7 of bison.info).
>
>In my case no ambiguity is being reported (I am in glr mode
>after all ;-). But the parse stacks are not being reduced as
>expected (all three are in the state I would expect them to be
>in when the second typedef token is encountered).
>
>Does anybody have any ideas on how I can force yyparse
>to consider reductions in the number of parse stacks and
>thence reductions to the accept state?
In general, there is none, it seems. The idea of the GLR is that
reduce/reduce conflicts may split the deterministic parser, until the
ambiguity is resolved later in the parsing. The manual mentions the use of
%dprec to choose between different actions, but that seems to be it. (I am
not using %glr myself, so I am guessing here.)
You might try to rewrite your input grammar so that when the ";" of a
typedef is encountered, it reduces.
Alternatively, you might try an entirely new approach to your whole program
setup. You have not told us why you need this feature, to halt after each
statement. Is it imperative that the parser halts right after the statement
is finished? If not, assuming that the you have written a correct parser,
you might attempt to halt it in the actions. The feature is similar to that
of so called coroutines (part of Simula, for example). Coroutines can be
implemented using threads. So you might use threads to achieve the same
effect: Put the parser in a thread. Activate it. When an action where you
want the parser to halt is executed, as a part of the action, halt the
parser thread. Then do the other stuff you want to do. When parsing needs to
be resumed, reactivate the parser thread.
Hans Aberg
___
Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: Forcing multiple parse stacks to 'reduce'
At 19:24 + 2005/02/28, Derek M Jones wrote:
>>>I have written a parser for C that processes
>>>a single statement or declaration at a time.
>>>So after each statement/declaration yyparse
>>>returns.
>>
>>Bison is clearly not built to handle such applications. The normal thing is
>>to handle the whole language in one go. (How do you handle environments,
>>like "{...}" statement-by-statement?)
>
>I don't see why not. Bison is built to handle grammars.
>My grammar does not support sequences of statements
>or declarations. The whole language, in my case, consists of
>one statement or one declaration (which includes the
>header of a function definition). Characters such as { }
>are not part of the grammar (they are handled by a higher
>level routine).
You are clearly not parsing the full C language then, but some subsets. It
is hard to for me to judge, as I do not know what you are doing.
>My aim is to parse the visible source (i.e., preprocessing
>directives are ignored). Error recovery is better if
>statements/declarations are parsed individually.
LALR(1) usually provides very basic error recovery, as the states LR(1) are
merged together in a way that when an error token is detected, reductions
may become performed before the error is reported. So LR(1) might be better,
but Bison does not support that yet.
>'Errors'
>might be caused by conditional preprocessor directives
>that select how a statement, for instance, should be processed.
C in reality has two languages, a preprocessor language, that produces a
single stream as output. Then that stream is parsed by the actual C
compiler. If you want to get inputs on how to sync that for error reoprting,
you check out te GNU GCC compiler.
>Single statement/declaration at a time localises syntax errors.
But if that is your only motivation, it does not seem mecessary to actually
abort the compilation process, to read one statement at a time.
>>You might try to rewrite your input grammar so that when the ";" of a
>>typedef is encountered, it reduces.
>
>My question is how do I do that? My grammar is copied
>straight from annex A of the C Standard (plus six or so %dprecs
>and two changes from right recursion to left recursion).
See my other reply. I have a vague memory that people have better ways to
use a LALR(1) grammar with C. Check the newsgroup comp.copmilers and its
FAQ, published there monthly. The original grammar fomr the standrad is
probaly unsuitable for direct LALR(1) implementation.
>I am guessing that some form of lazy evaluation is being used
>internally by Bison.
No.
>After all, in most cases an end-of-file
>indicator is used to force reductions.
This is just a consequence of how the LALR(1) algorithm works. See for
example the AHO et all "Compilers...) ("Dragon") book. For a given input
grammar, one creates an new "augmented" grammar with an endmarker. Provides
push-down automaton is created from that. One is thus parsing a sentence
with a given endmarker, which must be provided by the lexer.
Hans Aberg
___
Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: Forcing multiple parse stacks to 'reduce'
At 15:38 + 2005/03/01, Derek M Jones wrote:
>I suddenly realised that the token sequence:
>
>typedef x y;
>typedef i j;
>{
>
>is a syntactically valid function definition.
So it seems, but I have not been able to figure out which function. :-) The
problem is that C has some grammar difficulties.
>Bison is correct not to perform the reductions I was
>expecting. Until a {, or EOF, is seen it does not it does not
>know whether it is dealing with a function definition or a
>list of declarations.
I have some vague memory that somebody found (fairly late, in the 90'ies) a
grammar transformation to make C becoming LALR(1) (modulo the usual context
tweaks for "typedef", etc.) Then you would not need using the %glr option.
You might check the newsgroup comp.compilers and its FAQ, published there
monthly.
Hans Aberg
___
Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: Identifying rule responsible for lookahead
At 12:46 -0800 2005/02/28, Soumitra Kumar wrote: >Following is a sample grammar. There is one r/r >conflict. > >% cat test.y >%token YYID YYDOT >%% >identifier : hier_id >; >hier_id : simple_id >| hier_id opt_select YYDOT simple_id >; >opt_select : >| opt_select '[' expr ']' >; > >simple_id : YYID ; >expr : hier_id >| function_call >; >function_call : expr YYDOT YYID >; >% bison -r all -v test.y -g >test.y: conflicts: 1 reduce/reduce > >>From test.output: >state 10 > >3 hier_id: hier_id . opt_select YYDOT simple_id >4 opt_select: . [YYDOT, '['] >5 | . opt_select '[' expr ']' >7 expr: hier_id . [YYDOT, ']'] > >YYDOT reduce using rule 4 (opt_select) >YYDOT [reduce using rule 7 (expr)] > >YYDOT is in the lookahead set of rule 7 (expr: >hier_id) because of rule 9 (function_call: expr YYDOT >YYID). > >If nonterminal expr is used is many rules, it gets >difficult to find out which usage is causing problem. > >Basically I want to annotate the rules responsible for >a lookahead token as follows. > >state 10 > >3 hier_id: hier_id . opt_select YYDOT simple_id >4 opt_select: . [YYDOT (3), '[' (5)] >5 | . opt_select '[' expr ']' >7 expr: hier_id . [YYDOT (9), ']' (5)] > >YYDOT reduce using rule 4 (opt_select) >YYDOT [reduce using rule 7 (expr)] > >I was wondering if there is a way to get this >information out of bison. The problem is how to extract the information from the LALR(1) algorithm, if possible. Do you have any suggestion? (I may think a bit more on the question.) It is otherwise not a help-bison issue, but a "featuritis" issue, which normally should be posted in the bug-bison list. Hans Aberg ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: Identifying rule responsible for lookahead
Please keep the cc to help-bison so that others may help. On 2005/03/02 00:38, Soumitra Kumar at [EMAIL PROTECTED] wrote: > Thanks for your comment. > I thought there may be a way to get this information > from --trace option, that's why I posted on help-bison > list. The question is how. > I have read the LALR(1) and bison algorithm (I forgot > the author's name). I was wondering if there is any > design document of bison. Actually I had tried to hack > bison code to print it, but could not. If there any > documentation it would help. No, there is no such Bison design doc's: Only reading the Bison source code itself. (Apart from that somebody wrote something in Spanish, I think.) > -Soumitra. > >> >> The problem is how to extract the information from >> the LALR(1) algorithm, if >> possible. Do you have any suggestion? (I may think a >> bit more on the >> question.) >> >> It is otherwise not a help-bison issue, but a >> "featuritis" issue, which >> normally should be posted in the bug-bison list. >> >> Hans Aberg > > > > __ > Do you Yahoo!? > Yahoo! Mail - Find what you need with new enhanced search. > http://info.mail.yahoo.com/mail_250 ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: Forcing multiple parse stacks to 'reduce'
On 2005/03/02 17:07, Derek M Jones at [EMAIL PROTECTED] wrote: >> I have some vague memory that somebody found (fairly late, in the 90'ies) a >> grammar transformation to make C becoming LALR(1) (modulo the usual context >> tweaks for "typedef", etc.) Then you would not need using the %glr option. >> You might check the newsgroup comp.compilers and its FAQ, published there >> monthly. > > I have a lalr(1) grammar for C (who doesn't?). The first edition > of Harbison&Steele list the output from such a tool for C. There is nothing such in my Harbison&Steele (4th ed.). The comment I recall was that I think it was Paul Hilfinger who asked Bjarne Stroustrup (in cmop.compilers) why certain C++ ambiguities where in that language, and the latter replied it had to do with the fact that they had not a C LALR(1) grammar at the time the designed those C++ features. But my memory could be wrong. Hans Aberg ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: x + (y) + z
At 20:41 + 2005/03/03, Derek M Jones wrote: >The statement (y)+z can be parsed as casting >+z to the type y, or as adding y to z. A couple of >%dprecs solve this problem (I think the cast is the >common case for - and a binary expression for +). The normal way to resolve this would be to let the lexer check the lookup table to see what y is: a type or a number identifier, and then return that type. WHy does this not work for you. >However, things are more complicated for x + (y) + z, >whose parse tree can be either > >+ > /\ > x ( ) > / \ > y + > | > z > >or > > + > / \ >+ z > / \ > x(y) > >As currently implemented the %dprec functionality does >not appear to be any help here. Effectively, it will only >select between two productions that consume the same >number of input tokens. The commands %left and %right handles left and right associativity. Hans Aberg ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: x + (y) + z
At 14:43 + 2005/03/05, Derek M Jones wrote: >>The normal way to resolve this would be to let the lexer check the lookup >>table to see what y is: a type or a number identifier, and then return that >>type. WHy does this not work for you. > >Because I don't have a symbol table to look things up in. >Perhaps I should have pointed this out (it also answers >Frank Heckenbach's question). When parsing the visible >source (ie not doing any preprocessing; well apart from >ignoring the directives) a statement/declaration at a time >the content of a symbol table are likely to be very incomplete. You are not processing the C language, but some other language, with the context dependencies of the C language removed. Perhaps check the newsgroup comp.comilers for better input on that problem. >>The commands %left and %right handles left and right associativity. > >Good alternative suggestion. But this still requires tree rewriting >after the expression has been parsed. My %gooa option proposal >avoids this grammar violence. Featuritis should be posted in bug-bison. You can only expect to get such features into Bison if there is someone willing to volunteer doing the work. Alternatively, you might introduce a new token-name both for type-names and number-names. I.e., instead of %token type-name number-name you write %token token-type-name %% type-name: token-type-name; number-name: token-type-name; You then get a correct GLR parse, and can try to sort out the ambiguity later. Hans Aberg ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: x + (y) + z
At 17:03 + 2005/03/06, Derek M Jones wrote: >>You are not processing the C language, but some other language, with the >>context dependencies of the C language removed. > >Correct. I only claim to be processing C syntax on a >single statement/declaration basis (and then only at the visible >source level).. >>Alternatively, you might introduce a new token-name both for type-names and >>number-names. I.e., instead of >>%token type-name number-name >>you write >>%token token-type-name >>%% >>type-name: token-type-name; >>number-name: token-type-name; >> >>You then get a correct GLR parse, and can try to sort out the ambiguity >>later. > >I don't understand what you are getting at here. You ignore the context information distinguishing between type-names and number-names. So set these names equal to the same token, and let the GLR parser handle it. It then produces all correct parses, including the possible type-name/number-name choices. You then get the correct parse trees, and need only decide how to select one over the other. Clearly, this choice cannot be done, in general, unless you somehow supply the context information missing. Hans Aberg ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: x + (y) + z
At 18:12 + 2005/03/06, Derek M Jones wrote: >> You then get the correct parse >>trees, and need only decide how to select one over the other. Clearly, this >>choice cannot be done, in general, unless you somehow supply the context >>information missing. > >Unfortunately glr parsing is not a universal solution. It requires that >at the end of processing there be a unique parse tree (the multiple >parse trees that may exist while processing the input tokens are required >to eventually resolve to a single parse). Paul Hilfinger is thinking about actions that during a split are executed immediately, in addition to those delayed until the merge. This will enable the kinds of things that you are asking for, I think, as one then can build the parse trees, and make a selection based on that. Otherwise, you seem to simply ask for nondeterministic parsing, where one keeps track of all the parsing possibilities. Such parsers are not difficult to write, see for example the Parsing Techniques book: http://www.cs.vu.nl/~dick/PTAPG.html Such parsers are especially easily written in a functional language, like Haskell <http://haskell.org>. If you check the Haskell site, or list, you might find one for you. The problem is though that these are very slow, with stress on very: In once replaced one with a Flex-Bison combination (on the Mini-Prolog that comes with Hugs), and a very slow program became lightning fast. But with your problem at hand, you may have no choice. Hans Aberg ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: x + (y) + z
At 18:12 + 2005/03/06, Derek M Jones wrote: >Unfortunately glr parsing is not a universal solution. It requires that >at the end of processing there be a unique parse tree (the multiple >parse trees that may exist while processing the input tokens are required >to eventually resolve to a single parse). You can try using %merge, and then in the merge action function build in the split-parse info. (For example, registering the different parses.) Hans Aberg ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: x + (y) + z
At 02:14 + 2005/03/07, Derek M Jones wrote: >>Paul Hilfinger is thinking about actions that during a split are executed >>immediately, in addition to those delayed until the merge. This will enable >>the kinds of things that you are asking for, I think, as one then can build >>the parse trees, and make a selection based on that. > >I think the only way forward is for me to write some code, in yyparse, >to select between the various parses when an ambiguity is detected. You must merge them at some point, but you might use %merge to keep track of the both parses using a merge-function then. (See the Bison manual, sec 1.5.2.) Hans Aberg ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: x + (y) + z
At 16:06 + 2005/03/07, Derek M Jones wrote: >Frank, ... >Your grammar contained a single %merge. I thought at >least two are required? I think that you should just merge together the tokens becoming indistinguishable by your exclusion of context-information. You then get certain reduce/reduce conflict. These can then be merged together using %merge. If you need to keep track of the different parses somehow, encode that in the merge function. This method, if it works, will be considerably faster than using any more general nondeterministic parsing method that keeps track of all the different parses without merging them. Hans Aberg ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: ERROR: version file does not exist or are not readable
You must provide more info about when and how the error occurs (version, installation, etc.): I can't find that error string in Bison 2.0 nor in the M4 that Bison uses. If you use an older Bison version, try to update, as older versions are not supported. And bugs should be reported to the Bug-Bison list. At 16:04 +0100 2005/03/08, <[EMAIL PROTECTED]> wrote: >When I try to run bison I get folowing: > >ERROR: version file does not exist or are not readable > > > > >___ >Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: Question about "Conditions for Using Bison" in Bison 2.0 documentation
This is most likely an error: The other skeleton files did not exist at the time that stuff was written. Akim Demaille is resposnible for the C++ file and Paul Hilfinger for the GLR file. They probably forgot to insert the correct copyright. If so, this is a Bug-Bison issue. At 14:28 +0100 2005/03/09, Michel Rosien wrote: >Hello, I have read the "Conditions for Using Bison" on page 3 of the Bison 2.0 documentation. The first lines say: As of Bison version 1.24, we have changed the distribution terms for yyparse to permit using Bison's output in nonfree programs when Bison is generating C code for LALR(1) parsers Does this mean that this only applies when using the skeleton file yacc.c and that this NOT applies when using the skeleton files glr.c or lalr1.cc? This would mean that you can not make glr parsers (%glr-parser) or c++ parsers if you want to use the output in nonfree programs. The last lines of the "Conditions for using Bison" mention: You can tell whether the exception applies to your '.c' output file by inspecting it to see whether it says "As a special exception, when this file is copied by Bison into a Bison output file, you may use that output file without restriction." If I inspect the skeleton files yacc.c , glr.c and lalr1.cc I see that only yacc.c contains this text. Is this correct? If so, could you explain why this distinction is made? Regards, --Michel___ >Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: Question about "Conditions for Using Bison" in Bison 2.0 documentation
It would simplify if the supported Bison skeleton files were distributed under the same copyright. The unsupported skeleton files, if any, should be put in a special place, either in the distribution, or outside it, I think. At 12:50 -0800 2005/03/09, Paul Hilfinger wrote: >In fact, this issue did get discussed when the GLR skeleton got >introduced, and the language (or lack of it) is, AIR, deliberate on >the part of the lead maintainers at the time. On consideration, I >would prefer that the same terms apply to all skeletons as now apply >to the C LALR(1) skeleton. I think that there does come a point at >which copylefting becomes shooting oneself in the foot. > >The best presentation I've seen of the GPL for the corporate audience >goes something like this: > >If your lawyer takes a look at the GPL, he should say something >like, "Hmm, well this appears to be a pretty ordinary license that >allows us to use this software under certain conditions. >Hello---my word, these conditions certainly are liberal. >Apparently, we don't have to pay any royalties (unlike your typical >Microsoft license), we are free to reverse engineer (unlike your >typical Microsoft license), to examine the source (UYTML), >to modify (UYTML), to redistribute (UYTML), and even to >publicly vilify (UYTML)." > >How strange then that use of the OUTPUT from using such a program >should be more strictly controlled than is the output of MS Word! > >In short, I am strongly in favor of making the terms of use for Bison >output uniformly liberal across skeletons. > >Paul Hilfinger > > > > This is most likely an error: The other skeleton files did not exist at the > > time that stuff was written. Akim Demaille is resposnible for the C++ file > > and Paul Hilfinger for the GLR file. They probably forgot to insert the > > correct copyright. If so, this is a Bug-Bison issue. > > > > At 14:28 +0100 2005/03/09, Michel Rosien wrote: > > >Hello, =A0 I have read the "Conditions for Using Bison" on page 3 of t >h= > > e > > Bison 2.0 documentation. The first lines say: =A0 As of Bison versio >n > > 1.24, we have changed the distribution terms for yyparse to permit using > > Bison's output in nonfree programs when Bison is generating C code for > > LALR(1) parsers =A0 Does this mean that=A0this only applies when > > using the skeleton file=A0yacc.c and that this NOT applies when using the > > skeleton files glr.c or lalr1.cc? This would mean that you can not make glr > > parsers (%glr-parser) or c++ parsers if you want to use the output in > > nonfree programs. =A0 The last lines of the "Conditions for using Bison" > > mention: You can tell whether the exception applies to your '.c' > > output file by inspecting it to see whether it says "As a special > > exception, when this file is copied by Bison into a Bison output file, you > > may use that output file without restriction." =A0 If I inspect > > the skeleton files yacc.c , glr.c and lalr1.cc I see that only yacc.c > > contains this text. =A0 Is this correct? If so, could you explain why this > > distinction is made? =A0 Regards, =A0 > > --Michel___ > > >Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison > > > > > > ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: Question about "Conditions for Using Bison" in Bison 2.0 documentation
At 10:53 +0100 2005/03/10, Sylvain Schmitz wrote: >Paul Hilfinger wrote: > >> In fact, this issue did get discussed when the GLR skeleton got >> introduced, and the language (or lack of it) is, AIR, deliberate on >> the part of the lead maintainers at the time. On consideration, I >> would prefer that the same terms apply to all skeletons as now apply >> to the C LALR(1) skeleton. I think that there does come a point at >> which copylefting becomes shooting oneself in the foot. > >This looks to me as a problem of competitive advantage: if bison was one >of the only programs providing C++ or GLR parsers generation, it could >be seen as a way to promote GPLed software. It might have been true >when these skeleton first appeared, but I don't think it is any more, >since both commercial and open source implementations exist now. In >which case it seems to me that the opposite attitude is better, that is >promote the use of bison with an unrestrictive license on the skeletons, >and hope it will promote the use of other open source software. One other way to view this is that the output of a copyrighted program is rarely viewed as being covered by the copyright of the program that made it. Take, for example, the text-files produced by a copyrighted program. Hans Aberg ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: ERROR: version file does not exist or are not readable
Please keep the cc to help-bison, so others know. When you get the right bison installed, its version can be checked by the --version option. At 08:42 +0100 2005/03/10, <[EMAIL PROTECTED]> wrote: >The error where not generated by bison. When I test with "which bison" I found that the computer use some other program that also is called bison. So, when I change the path everything works correctly. > >-Ursprungligt meddelande- >Från: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] Hans >Aberg >Skickat: onsdagen den 9 mars 2005 19:24 >Till: Olsson Magnus (VN-PRRT) >Kopia: help-bison@gnu.org >Ämne: Re: ERROR: version file does not exist or are not readable > > >You must provide more info about when and how the error occurs (version, >installation, etc.): I can't find that error string in Bison 2.0 nor in the >M4 that Bison uses. If you use an older Bison version, try to update, as >older versions are not supported. And bugs should be reported to the >Bug-Bison list. > >At 16:04 +0100 2005/03/08, <[EMAIL PROTECTED]> wrote: >>When I try to run bison I get folowing: >> >>ERROR: version file does not exist or are not readable >> >> >> >> >>___ >>Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison > > > > >___ >Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: Question about "Conditions for Using Bison" in Bison 2.0 documentation
[For some unknown reason, my email to Paul Eggert bounces.] Paul Eggert's comment does not prove commonness :-), except perhaps in the case of Yacc and related programs. When I try to think about computer software in general, it always is the principle that Paul Hilfinger indicates. If the program owner would be able to copyright also the output from a program, it would be in practise impossible to use such programs. (Think of rendering programs for movies, text editors, typesetting programs, audio and DVD players, etc.) As for the copyrighting issue itself, it rarely goes to court. Isn't there only about one case where the GPL has been tried in court? At 14:04 -0800 2005/03/10, Paul Hilfinger wrote: > > Hans Aberg <[EMAIL PROTECTED]> writes: > > > > > the output of a copyrighted program is rarely viewed as being > > > covered by the copyright of the program that made it. > > > > No, actually it's quite common. For example, if I run the traditional > > /usr/ccs/bin/yacc that is shipped with Solaris 9, the output file > > y.tab.c contains the following lines: > > > > /* > > * Copyright (c) 1993 by Sun Microsystems, Inc. > > */ > > > > There is no other wording granting permission to copy, so under the > > Berne convention you have no right to copy the output file y.tab.c > > unless you have some other agreement with Sun. > >Actually, I believe that the Berne convention gives no standing >whatever to written copyright notices of this sort. Instead, if I >produce a copyrightable work, that work is protected by copyright >unless I take steps to make it otherwise. Here the issue is works >that are produced by the operation of copyrighted software. I don't >know what the default status is of works produced by X's use of Y's >copyrighted programs, but I rather suspect that such products belong >to X unless the license granted to X by Y explicitly makes other >provisions. > >Paul Hilfinger > > >___ >Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: Question about "Conditions for Using Bison" in Bison 2.0 documentation
At 15:11 -0800 2005/03/10, Paul Eggert wrote: >> I don't know what the default status is of works produced by X's use >> of Y's copyrighted programs, but I rather suspect that such products >> belong to X > >It depends on whether the produced works are "derivative works" of Y's >copyrighted programs. For many programs (e.g., "cat") it's quite >clear that the program's output is not a derivative work of the >program. > >But in the case of Yacc, it's pretty clear that the C output file is a >derivative work of both the Yacc template file and the user's source >file. So, legally speaking, the user and Sun both have copyright >interest in the C output file, and you need permission from both >parties before you can redistribute that file. This is interesting: First it means that it is wrong for Yacc/Bison to put a single copyright on the output file. But also, second, it is a tricky question what copyrighted material one can use for free. I believe that news reporting can include copyrighted quotes and such, without having to oblige to the original copyright. Copyright is essentially a business protection law, and freedom of speech laws have precedence. Hans Aberg ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: Identifying rule responsible for lookahead
At 01:10 -0500 2005/03/11, Alfonso Urdaneta wrote: >> No, there is no such Bison design doc's: Only reading the Bison source code >> itself. (Apart from that somebody wrote something in Spanish, I think.) > >link ? It was a Spanish fellow "CJ" <[EMAIL PROTECTED]>, writing a thesis on his tutor's DR algorithm; see the Bug-Bison list around 2001-2002. For example: At 23:50 +0100 2001/06/17, CJ wrote: > I have allocated the tesis in ps format in this location FTP: host club2.telepolis.com password: chinijo the file is drlr.zip Perhaps Akim Demaille knows more about this, and what the stuff in Spanish is located. It might be interesting to produce some draft in English, and then make a description of Bison internals, as the question pos up every know and then. I also found this: At 21:19 + 2002/09/11 in Help-Bison, Carlos Javier Borges Villalba <[EMAIL PROTECTED]> wrote: Subject: Re: if you can speak spanish you wil be lucky >In this url http://club.telepolis.com/bisondr >there is a document where you can find information about Bison, how its >construct the LALR automaton, how it solve conflicts.. is in >spanish. It is not right version, next week it will be available. Sometimes >the url is wrong but try it later there is the document. > >I hope it will be useful. And if you have suggest you can email me. Surely I >will put the source latex in that url. Hans Aberg ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
unixodbc and yy_flush_buffer (2.0)
At 11:25 -0400 2005/03/18, Alejandro Mery wrote: Hi, i'm trying to build unixodbc-2.2.11 with bison-2.0. i worked around for >YY_FLUSH_BUFFER macro, but the symbol itself is not defined. everyone say, "don't use newer bison-s" but i would like to do it, and patch >unixodbc acordingly. yy_flush_buffer is a feature of Flex. So try the Help-flex mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/help-flex can you give me any hit to solve this issue? Did I hit you well enough? :-) -- Hans Aberg ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: Grammar definition problem.
In addition, note that most wold put this stuff in the lexer
(generated say by Flex).
At 14:55 +0530 2005/03/21, Atul Kulkarni wrote:
Hi All,
I am facing problem in defining the following grammar for Bison.
X -> letter { letter | digit }.
here letter and digit are terminals and X is the non terminal symbol.
I am not able to put this rule in the bison grammar form hence need
some advice on this.
in particular I am not able to express the
letter AND {letter OR digit } rule in the Bison grammar.
how do I put the OR part of the rule inconsideration of the fact that
that scentence has to start with the "letter" and later have any
number of of digit?
Regards,
Atul.
___
Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
___
Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: %union errors that shouldn't be there
At 11:55 +0100 2005/03/21, Laurence Finston wrote: On Sun, 20 Mar 2005, DYP wrote: In file included from misery.ll:30: gram.yy:26: error: ISO C++ forbids declaration of `astNode' with no type gram.yy:26: error: expected `;' before '*' token gram.yy:27: error: ISO C++ forbids declaration of `string' with no type gram.yy:27: error: expected `;' before '*' token gram.yy:28: error: ISO C++ forbids declaration of `nodeList' with no type gram.yy:28: error: expected `;' before '*' token Apparently, your types `astNode', `string', and `nodeList' are undefined when your `%union' declaration is being compiled. Assuming you're using C, My guess is that you're not including the header file or files that declare them in your parser input file. On the other hand, if you're using C++, it might be because these are types that can't be included in `unions'. I don't remember the rule off-hand --- it has something to do with constructors and/or destructors. I don't know whether this programming error would cause this particular compiler error to be signalled, though, and I don't have time to test this myself at the moment. They should be OK in C++, as pointers do not have non-trival con-/de-structors. The compiler needs to see a declaration of the name as a type, though, before it sees the pointer. -- Hans Aberg ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: %union errors that shouldn't be there
It looks as though the C++ compiler does not see the declaration of
the types astNode, string (is it std::string?), nodeList, before it
sees the union that the parser implements. So, you have to make sure
that info is included somewhere, perhaps in the %{ ... %} segment
before the %union in the .y file.
At 16:57 -0500 2005/03/20, DYP wrote:
Hello,
My %union is declared in the following way and does have the proper
header file included but I still get errors that should not be there.
%union{
float fconst;
int type;
astNode* node;
string* name;
nodeList* list;
}
Here are the errors that I get when trying to compile the bison
generated file
In file included from misery.ll:30:
gram.yy:26: error: ISO C++ forbids declaration of `astNode' with no type
gram.yy:26: error: expected `;' before '*' token
gram.yy:27: error: ISO C++ forbids declaration of `string' with no type
gram.yy:27: error: expected `;' before '*' token
gram.yy:28: error: ISO C++ forbids declaration of `nodeList' with no
type
gram.yy:28: error: expected `;' before '*' token
I just don't see what I am doing wrong.
Your help is appreciated.
___
Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
--
Hans Aberg
___
Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
RE: %union errors that shouldn't be there
Don't forget to cc Help-Bison, so others know that your problem has
been solved.
At 13:26 -0500 2005/03/21, Dmitry Podkuiko wrote:
Thanks for your response Hans. Indeed, it had do with #include's being in
the right order. The y.tab.h file has to be the last included and I had it
first in the list which caused it not to see the definitions of my classes
and even the std::string even though I included using namespace std;. Thank
You.
Dmitry.
-Original Message-----
From: Hans Aberg [mailto:[EMAIL PROTECTED]
Sent: Monday, March 21, 2005 1:17 PM
To: [EMAIL PROTECTED]
Cc: help-bison@gnu.org
Subject: Re: %union errors that shouldn't be there
It looks as though the C++ compiler does not see the declaration of
the types astNode, string (is it std::string?), nodeList, before it
sees the union that the parser implements. So, you have to make sure
that info is included somewhere, perhaps in the %{ ... %} segment
before the %union in the .y file.
At 16:57 -0500 2005/03/20, DYP wrote:
Hello,
My %union is declared in the following way and does have the proper
header file included but I still get errors that should not be there.
%union{
float fconst;
int type;
astNode* node;
string* name;
nodeList* list;
}
Here are the errors that I get when trying to compile the bison
generated file
In file included from misery.ll:30:
gram.yy:26: error: ISO C++ forbids declaration of `astNode' with no type
gram.yy:26: error: expected `;' before '*' token
gram.yy:27: error: ISO C++ forbids declaration of `string' with no type
gram.yy:27: error: expected `;' before '*' token
gram.yy:28: error: ISO C++ forbids declaration of `nodeList' with no
type
gram.yy:28: error: expected `;' before '*' token
I just don't see what I am doing wrong.
Your help is appreciated.
___
Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
--
Hans Aberg
___
Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: Grammar definition problem.
Please continue to cc the Help-Bison list, so that more can help.
Often one is using a program like Flex to generate a lexer, a program
that tokenizes the input. Then the Bison generated parser gets token
number to parse. This kind of setup is described, for example, in the
book by Aho, Sethi & Ullman, "Compilers..." (the "Dragon Book").
At 10:12 +0530 2005/03/22, Atul Kulkarni wrote:
hi,
Read your reply on the Bison mailing list, but failed to under stand
your point. Can you please explain?
Regards,
Atul.
On Mon, 21 Mar 2005 19:18:28 +0100, Hans Aberg <[EMAIL PROTECTED]> wrote:
In addition, note that most wold put this stuff in the lexer
(generated say by Flex).
At 14:55 +0530 2005/03/21, Atul Kulkarni wrote:
>Hi All,
>I am facing problem in defining the following grammar for Bison.
>
>X -> letter { letter | digit }.
> here letter and digit are terminals and X is the non terminal symbol.
>
>I am not able to put this rule in the bison grammar form hence need
>some advice on this.
>
>in particular I am not able to express the
>
>letter AND {letter OR digit } rule in the Bison grammar.
>
>how do I put the OR part of the rule inconsideration of the fact that
>that scentence has to start with the "letter" and later have any
>number of of digit?
>
>
>Regards,
>Atul.
>
>
>___
>Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
___
Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: %union errors that shouldn't be there
At 10:39 +0100 2005/03/22, Laurence Finston wrote: On Mon, 21 Mar 2005, Hans Aberg wrote: They should be OK in C++, as pointers do not have non-trival con-/de-structors. The compiler needs to see a declaration of the name as a type, though, before it sees the pointer. If I remember correctly, it has to do with the size of the objects not being known at the time the `union' declaration is compiled. I'm not sure, but I think I tested this once and discovered, somewhat to my surprise, that using pointers in the `union' didn't work, either. When I get a chance, I'll check this carefully. With unions, the problem is, if con-/de-structors are non-trivial, that it is impossible to know which ones to apply and when. The union does not contain any type information which field is selected. If one adds that, unions with non-trivial con-/de-Structors would be possible. -- Hans Aberg ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: %union errors that shouldn't be there
At 14:16 +0100 2005/03/23, Laurence Finston wrote:
> The union does not
contain any type information which field is selected. If one adds that,
unions with non-trivial con-/de-Structors would be possible.
Add it where?
Just add a field, invisible to the user, with the type information.
Dynamic allocations must have such a field with the size, so that it
can be properly deallocated. So it nothing strange as such. In fact,
one can do thi by hand:
class Union {
public:
typedef Type int;
union Value {
...
};
Type type;
Value Value;
};
Then write the class Union as to hide away the constructor stuff.
Perhaps Bison should support such a version. Then one does not need
to use the %destructor stuff. The drawback is the extra memory each
int takes on the parser stack.
I suspect that doing so in C++ would break compatibility
to C.
Not really, as C and C++ are different languages. One would need to
be aware that the C++ unions
I haven't checked whether any C++ implementation has
implemented such a facility as an extension, though.
Doubt it. The C++ paradigm is to use a class hierarchy instead.
It might be possible to implement a way of using class types with
constructors and destructors in a `%union' in Bison, but not with an
unextended C or C++ union. This is just my opinion, but I think it's
simpler to just use `void*'.
So you have a suggestion of an extended union above.
--
Hans Aberg
___
Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: %union errors that shouldn't be there
At 19:34 +0100 2005/03/23, Laurence Finston wrote:
On Wed, 23 Mar 2005, Hans Aberg wrote:
At 14:16 +0100 2005/03/23, Laurence Finston wrote:
>Add it where?
Just add a field, invisible to the user, with the type information.
I meant "in C++ or in Bison?"
In the context, I though you meant extending union in the C++
language. But this lead to the idea to do it by hand within the
current language. Then Bison might support it.
> Dynamic allocations must have such a field with the size, so that it
can be properly deallocated.
Yes, this information must be stored somewhere. However, when
programming applications in C++, one usually doesn't have to worry about
the sizes of objects. Even when using C, I usually just use `sizeof()'.
So it nothing strange as such. In fact,
one can do thi by hand:
class Union {
public:
typedef Type int;
union Value {
...
};
Type type;
Value Value;
};
Yes, but this isn't a `union' anymore.
It would not be the old union, but a new union with new required
semantics, that is clear.
> >I suspect that doing so in C++ would break compatibility
>to C.
Not really, as C and C++ are different languages.
The compatibility of C++ to C is not complete but reasonably close.
I think this is one of the best and most important features of C++.
If C++ was less compatible to C, it's quite possible that I wouldn't be
able to use it in my parser rules.
Personally, I think this is one of the biggest hurdles with C++,
because it inherits all C language quirks.
--
Hans Aberg
___
Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: %union errors that shouldn't be there
At 19:34 +0100 2005/03/23, Laurence Finston wrote: > One would need to be aware that the C++ unions The rest of this sentence was missing. If one adds such semantics to the C++ union, one needs to be aware of that it differs from that of the C union. I think this should be without problem, as one cannot only mix the two languages using 'extern "C"' linkage from C++ for functions only. Perhaps there is a problem if the function has a C union as an argument. But then it does not have any non-trivial constructors to keep track of. So perhaps it works. -- Hans Aberg ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: %union errors that shouldn't be there
At 11:10 +0100 2005/03/24, Laurence Finston wrote: > It would not be the old union, but a new union with new required semantics, that is clear. My point was that `union' is an element of the C and C++ languages, whereas your new `Union' class would not be. I think this is important, others may not. This discussion is very confusing, because it mixes two topics: Extending C++, and what is appropriate for Bison. As for the latter question, one would have to give iyt a different name that %union. But with the %typed and other features suggested here (%define), that would not be a problem. > >The compatibility of C++ to C is not complete but reasonably close. >I think this is one of the best and most important features of C++. Personally, I think this is one of the biggest hurdles with C++, because it inherits all C language quirks. Stroustrup gives very thorough explanations of why he decided to do it this way and is very open about the disadvantages. There is no free lunch. It certainly makes it easier for a C programmer to start using C++. If it were not so, I suspect it would make it more difficult or even impossible to do the kind of low-level programming with C++ that's possible with C. If this were so, it would make C++ useless from my point of view. (I know not everybody will agree me.) C++ has been developed over several decades. And some of the later C++ features have problems to coexist with C. -- Hans Aberg ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: Flex Problem, I did not find a list for Flex hence postin here.
At 16:06 +0530 2005/03/24, Atul Kulkarni wrote: I am putting the problem of Flex in this list due to lack of knowledge about Flex's mailing list and they are because normaly used in tandem with each other! Try: Help-flex mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/help-flex http://lex.sourceforge.net/ -- Hans Aberg ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: %union errors that shouldn't be there
At 14:56 +0100 2005/03/25, Laurence Finston wrote:
> This discussion is very confusing, because it mixes two topics:
Extending C++, and what is appropriate for Bison.
This is just my opinion, but I don't think adding type information to
`union'
would be in the spirit of C. If this feature were added, the first thing I'd
do would be to look for a way to turn it off.
It would be in the spirit of C++. :-)
> As for the latter
question, one would have to give iyt a different name that %union.
But with the %typed and other features suggested here (%define),
that would not be a problem.
No, but what would be the advantage over something like the following?
struct Yystype_Struct
{
unsigned short type;
void* object;
};
With unions, one wants to avoid dynamic allocations. Each dynamic
allocation takes several tens, sometimes, hundreds of cycles.
I don't understand why you would want to use `union' at all. Of course,
what's appropriate for Bison is up to the maintainers and developers, so I'll
stay out of that one. From my point of view as a user, it's perfectly simple
to use `void*' in `%union', and I suspect that it will be perfectly simple to
use it as `YYSTYPE' (I haven't tried it yet).
So what problem are you trying to solve?
Unions are faster than dynamic allocations, and in the past, it was
important that they take little space. One example where I have used
it is a series of function pointer of different type.
--
Hans Aberg
___
Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: %union errors that shouldn't be there
At 17:50 +0100 2005/03/26, Laurence Finston wrote: > With unions, one wants to avoid dynamic allocations. Each dynamic allocation takes several tens, sometimes, hundreds of cycles. If pointers are used, then memory needs to be allocated for the objects they point to, whether the pointers are in a `struct' or a `union'. It needn't be allocated dynamically in either case. I don't see any advantage to having multiple members of pointer types in a `union', e.g., I guess the cleanup is generally different. But use whatever you feel comfortable with. > Unions are faster than dynamic allocations, and in the past, it was important that they take little space. I have nothing against `unions'. I think if pointers are going to be used anyway, then a single `void*' could be used for all types, in which case there would be no need for a `union'. If class types are to be allowed, the constructors of objects of these types might be performing dynamic allocation, so it might not pay to take the trouble of avoiding it for the other types. I think it's an interesting problem. The idea with extended unions, avoiding pointers, would be to avoid having to do hand code special cleanup. -- Hans Aberg ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: A simple example of using bison++ and flex++
At 20:14 + 2005/03/27, Belaid MOA wrote: I noticed that there is an interest in having an example of using bison++ and flex++. I also noticed that there is no concrete example in the web (from my search). For this reason, this an example of how to use bison++ and flex++. Are you aware of that bison++ resp. flex++ are programs separate from bison and flex? These lists have nothing to do with those program. If you supply an example using Bison and Flex, that would be of interest on these lists. -- Hans Aberg ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: Help with shift/reduce conflict
As Henrik Sorensen points out, you need to be more specific about the
grammar you want to produce. Here is a suggestion though:
%token YYID
%%
expression:
hier_id
| method_call
| paren_expr
;
paren_expr:
'(' expression ')'
;
method_call:
paren_expr '.' YYID paren_expr
;
hier_id :
YYID
| hier_id '.' YYID
;
At 12:23 +0200 2005/03/28, Henrik Sorensen wrote:
On Monday 28 March 2005 00.20, Soumitra Kumar wrote:
1+3.YYID(7) has no meaning. But following is a valid
expression:
(YYID + YYID).YYID().YYID () + YYID() + YYID.YYID() +
YYID.YYID
for this reduction to make any sense, you need to show more of your grammar.
What kind of operator is '.' in your grammar ?
Henrik
-Soumitra.
--- Henrik Sorensen <[EMAIL PROTECTED]> wrote:
> can you tell a bit more about what your grammar
> tries to achieve ?
> from your very brief description, it sounds like you
> can do this:
> 1+3.YYID(7)
> but what would this mean ?
> Henrik
>
> On Sunday 27 March 2005 21.37, Soumitra Kumar wrote:
> > %token YYID
> > %%
> > expression : hier_id
> >
> > | method_call
> >
> > /* unary and secondary expression
>
> follows.
>
> > */
> > ;
> > method_call : expression '.' YYID '(' expression
>
> ')'
>
> > ;
> > hier_id : YYID
> >
> > | hier_id '.' YYID
> >
> > ;
> >
> > How to resolve the shift/reduce conflict? Please
>
> help.
>
> > -Soumitra.
> >
> >
> >
> > __
> > Do you Yahoo!?
> > Yahoo! Small Business - Try our new resources
>
> site!
>
> > http://smallbusiness.yahoo.com/resources/
> >
> >
> > ___
> > Help-bison@gnu.org
>
> http://lists.gnu.org/mailman/listinfo/help-bison
__
Do you Yahoo!?
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/
___
Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
___
Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
___
Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: flex++/bison++
At 17:58 -0800 2005/03/30, [EMAIL PROTECTED] wrote: hi, i'm interested in writing a flex/bison parser for a c++ project. i keep finding references to flex++/bison++ using google but they are all somewhat old links. is the latest version of flex/bison c++ compatible, do i need to worry about flex++/bison++ ? The programs bison++ and flex++ are supposedly unrelated to Bison and Flex. Latest Bison 2.0 and also Flex already has some C++ support, though it might be made more convenient. -- Hans Aberg ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: What about Flex/Bison tutorial's for newbies?
At 10:01 +0400 2005/03/31, Fallout wrote: I want to understand how to use this tool's... i do not find any good tutorial's about it (maybe i'm stupid and can't find it +) ) so what i mean... from grown to up... from simple to hard.. and so on... maybe anyone want to help to me with this problem... ? It depends on what level you want a tutorial. There are Lex/Yacc examples for example in the Flex/Bison manuals, and books like the one by Aho, Sethi & Ullman, "Compilers..." (the Dragon book). (Also see the FAQ of the newsgroup comp.compilers, published there monthly.) Then read use the before mentioned manuals and hang out in the before mentioned newsgroup. -- Hans Aberg ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re[2]: What about Flex/Bison tutorial's for newbies?
Please keep the cc to Help-Bison, so that others may help. I will email you a Flex-Bison setup example. At 09:03 +0400 2005/04/01, êÓÏýÌ wrote: áýÒÚÛÈÚÂ, Hans. Ç ÔËÒýÎË 1 ýÔÂÎþ 2005 ., 2:27:21: At 10:01 +0400 2005/03/31, Fallout wrote: I want to understand how to use this tool's... i do not find any good tutorial's about it (maybe i'm stupid and can't find it +) ) so what i mean... from grown to up... from simple to hard.. and so on... maybe anyone want to help to me with this problem... ? It depends on what level you want a tutorial. There are Lex/Yacc examples for example in the Flex/Bison manuals, and books like the one by Aho, Sethi & Ullman, "Compilers..." (the Dragon book). (Also see the FAQ of the newsgroup comp.compilers, published there monthly.) Then read use the before mentioned manuals and hang out in the before mentioned newsgroup. Tnx for help... Dmitry Podkuiko help me with this... heh i undestand BNF and know C... but i need some step by step example with Flex and Bison i buy Dragon Book in Russian heh this is very good book... but not to easy to undestand... +) -- ë ÛýÊÂÌËÂÏ, êÓÏýÌ mailto:[EMAIL PROTECTED] -- Hans Aberg ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Simple Flex/Bison example
Here is a simple calculator, using Flex and Bison. -- Hans Aberg calcex.tgz Description: Binary data ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: bison installation help!!!
[Sorry for the delay in reply: Your email got
spam classified, and was sorted away on my
computer.]
Have you tried to read the file INSTALL that comes with the bison distribution?
At 11:24 +0900 2004/10/18, mj Kang wrote:
p {margin-top:0px;margin-bottom:0px;}
dear
I'm interested in bison and I download bison
but i dont find install guide in bison's homepage
if anybody know how to install bison, plz let me know
thx.
"øÏ½Æ ¿Õð, Daum"
http://www.daum.net
Åwڪ澥¬ ¼´
· «-½Þ¿¦ðÅx
___
Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
___
Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: Bison version for PHP5.x installation on HPUX 11.11
At 14:45 -0700 2005/04/07, sidd_speak wrote: Would bison version 2.0 be the correct bison version to install on HPUX 11.11 as a part of the pre-installation requirements for PHP5.x? Would any other bison version work? It sounds as though you should pick down the sources at <http://www.php.net/>, and look into its makefile to see what it expects. Or the information should be there, somewhere, on that site, or some mailing list there, etc. -- Hans Aberg ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: Conflicts shift/reduction
At 21:16 +0200 2005/04/13, Eduardo Robles Elvira wrote: This is the bison output: lea.y: conflicts: 3 shift/reduce, 4 reduce/reduce lea.y:475.11-476.57: warning: rule never reduced because of conflicts: elif_statement_list: elif_statement How can I solve it ? The standard attempt to resolve shift/reduce conflicts, is to use the --verbose option, and in the .output file, in the afflicted state and rules, put precedences of the tokens right before and after the ".". As the Bison manual says, a reduce/reduce conflict may indicate a serious problem with the grammar. If you are sure the grammar is OK, you might try the %glr option. -- Hans Aberg ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: viewing parse tree
At 05:08 +0400 2005/04/14, hz kto wrote: I was wondering are there any tools out there that allow to view bison parse tree in graphics some sort of pseudo graphics, or any other way to help understand which branches of the parse tree depend on a particular grammar element. For example I want to find out all branches that might contain multiplication. If you want to see that parse tree, Bison does not provide any such thing, though there is a -g option, letting you to get a VCG graph of the pushdown automaton that Bison generates. You might inquiry in the group comp.compilers for such tools. In Bison, one uses normally the hands on approach, adding the stuff by hand the rule actions. -- Hans Aberg ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: Problem with a simple grammar
I have a simple bison file summarizes as #define YYSTYPE const char* ... When I run the program I got all members of prg having the same semantic value, i.e. all with the last string ($4). This is one of the most frequently asked question on this list: You forget to make copies of the strings in your lexer. Thus you only get a pointer into a buffer, as you work with pointers. PS. I have to use bison 1.24 so you may not be able to help me. This is rather old; the latest release is 2.0 -- Hans Aberg ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: Problem with a simple grammar
At 15:35 +0200 2005/04/17, Eulogio Serradilla wrote: > This is rather old; the latest release is 2.0 Yes, I know, but I prefer to wait for a C++ output for bison, as it says in the FAQ section of the manual. Bison already has some C++ support, though you might not get the file setup you may want. But if you are starting afresh, that might not be a problem to you. -- Hans Aberg ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: Problem with a simple grammar
At 19:44 +0200 2005/04/17, Eulogio Serradilla wrote: Actually, I'm using bison++ based on bison 1.19 and it works very well. When there is some documentation in bison about a C++ parser I will change my code. Bison++ is a program different from Bison, supposedly old. Bison has a C++ test, that is executed if you do a "make check". (I am using Bison 2.0 with a special tweak for my own C++ skeleton file, so that can't be used straight off.) -- Hans Aberg ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: error decoding before a numeric constant
At 18:35 +0200 2005/04/18, Eneko Nieto wrote: we have the following error while compiling with bison: error de decodificación antes de una constante numérica (in english must be something like "error decoding before a numeric constant") we have looked in the docs and google but haven't found any information about this error. Can anyone help us with the error or give us info about it? Are you using only Bison? Are you sure the error does not come from say GCC? -- Hans Aberg ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: error decoding before a numeric constant
At 20:41 -0400 2005/04/19, Alfonso Urdaneta wrote: Eneko Nieto wrote: Hello we have the following error while compiling with bison: error de decodificación antes de una constante numérica I didn't even know that bison had error messages in spanish. Are you sure they are coming from bison ? Have you checked po/, the files es.gmo es.po? It should be possible to natural language localize, though I do not know how. Those files, though, do not contain the indicated error message. -- Hans Aberg ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: New BISON version for VMS
At 11:43 +0200 2005/04/20, [EMAIL PROTECTED] wrote: I have a very old BISON version of year 1995 for VMS operating system. I need a new version, so I downloaded the software version 2.0. But I could not buld them on VMS, because the configure files etc. ware written for UNIX. Now I wand to know if you have a new BISON binary file for VMS, so that I can download it directly. If you do not have it, I hope I can get information about building BISON on VMS in greater detail, e.g. available configue files etc for VMS. Could you help me? Thank you very much in advance. By definition, GNU only supports POSIX, and all else are extra. If you are willing, or find someone willing, to make a VMS install, you might get help at the Bug-Bison list. -- Hans Aberg ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: Bison and embedded systems
At 11:29 +0200 2005/04/25, Julian Gryffin wrote: I need some help with Bison on embedded Systems. I have a ROM with only few memory. Bison is using dynamic memory in the C-file it built. Is there a possibility to prevent it using dynamic memory? My guess is that you do not use Bison on the embedded system, but merely want use the parser it generates. Then later versions of Bison are such that it should be easy to write ones own skeleton file. It can thus be designed to only use static memory, if you so would like. It should not be difficult to write such a skeleton file. I cc Paul Eggert, who wrote the dynamic memory feature; perhaps he can help. -- Hans Aberg ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: Bison and embedded systems
At 02:26 -0400 2005/04/26, Alfonso Urdaneta wrote: Paul Eggert wrote: If by "dynamic memory" you mean "malloc or alloca", then yes, it's easy: #define YYSTACK_ALLOC(size) 0 that _is_ easy. ;] Strictly speaking, one needs some additional information, fixing the initial parser stack size at a suitable value. I am not sure why alloca isn't usable in embedded systems; perhaps it is not available. And, if the parser stack is fixed, how is overflow handled. And if it is set too a high value, isn't that a poor use of the scarce memory? -- Hans Aberg ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: %destructor and stack overflow
Again, this is probably a question for Paul to answer, who wrote the current C-parser. I thought that the C-parser was dynamic, except when free store runs out, in which case one is toast anyway. What version of Bison are you using? Is it Bison 2.0? If you have disabled parser stack dynamic reallocation, and gets stack overflow, how do you intend to recover. I mean, then the parser cannot handle the input semantics properly anyway. At 22:39 +0200 2005/04/26, Marcus Holland-Moritz wrote: Hi, I've been using bison for the C parser in one of my perl modules for a couple of years now. (http://search.cpan.org/~mhx/Convert-Binary-C/) I recently noticed the %destructor feature and it looks as it would solve a problem that has long been on my todo list. Right now I'm collecting all objects that I don't reference otherwise in various lists so I can free them when the parser exits (when it exits normally, the lists are usually empty). However, maintaining these lists is time-consuming (both in programming time and execution time). I've now rewritten my parser to make use of %destructor, and it works fine generally. The only case where it doesn't work is when a parser stack overflow is detected. I can see from the generated parser code that a parser stack overflow error bypasses yydestruct(). My question: Is there a reason why the %destructor code isn't called upon parser stack overflow? I don't see a reason, because when the stack overflow is detected, the whole stack is still valid and even the items about to be pushed on the stack are valid and known to the parser. So it should at least be possible to do a correct cleanup of the parser stack. Thanks, Marcus -- One of the most overlooked advantages to computers is... If they do foul up, there's no law against whacking them around a little. -- Joe Martin ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: %destructor and stack overflow
At 00:09 +0200 2005/04/27, Marcus Holland-Moritz wrote: On 2005-04-26, at 23:46:10 +0200, Hans Aberg wrote: Again, this is probably a question for Paul to answer, who wrote the current C-parser. I thought that the C-parser was dynamic, except when free store runs out, in which case one is toast anyway. What Yes, it is dynamic. Up to YYMAXDEPTH. Besides, I don't think that anyone will ever get the parser to exhaust its stack. But my test suite checks the "parser overflow" error and that test will leak memory if any stray objects aren't cleaned up. Which is bad for the memory leak checker... Why don't you define YYMAXDEPTH to the MAXINT or something? Then you can only get overflow by memory running out. > parser stack dynamic reallocation, and gets stack overflow, how do you intend to recover. I mean, then the parser cannot handle the input semantics properly anyway. Sure. I don't want to recover. I just don't want to leak memory. As I mentioned, the parser is embedded in a Perl module, and the module shouldn't leak memory as the code using the module may run for long periods of time. There I do not see exactly what you need. Perhaps Paul can help. -- Hans Aberg ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: %destructor and stack overflow
At 21:20 +0200 2005/04/27, Marcus Holland-Moritz wrote: %destructor looks like it has the ability to be this "something better", but IMO it currently isn't as good as it could be (i.e. it is worse than my solution with regard to potential memory leaks arising from parser stack overflow). The intent of %destructor is to help cleanup during error stack unwinding. If one can somehow make a stack overflow cause an error, which in its turns causes the stack to unwind, then the cleanup would take place via %destructor. I think #define'ing YYMAXDEPTH to MAXINT (or any other XXL number) isn't a good idea. I know that no sane code requires the parser stack to be as large as 1000 items. So with YYMAXDEPTH = 1 I'm clearly on the safe side. And I prefer to have an error at a well-defined boundary rather than some part of the application running out of "real" memory when passed illegal input. So if you get a stack overflow error, what do you want to happen? Clearly, the parser must be taken down. You want it then to done so that stack cleanup takes place. Right? Possibly, the same cleanup actions as those in %destructor should be used. -- Hans Aberg ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: %destructor and stack overflow
At 22:47 +0200 2005/04/28, Marcus Holland-Moritz wrote: > So if you get a stack overflow error, what do you want to happen? Clearly, the parser must be taken down. You want it then to done so that stack cleanup takes place. Right? Possibly, the same cleanup actions as those in %destructor should be used. Yes, that's exactly what I'm talking about. When the parser detects a stack overflow, it should call the cleanup actions defined via %destructor for all symbols on the stack (and the symbol causing the overflow) before it returns. So then we know what you want to have. Here, I must ask Paul or Akim (who wrote the %destructor feature) help me out. -- Hans Aberg ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: warning: rule never reduced because of conflicts: @3: /* empty */
At 12:44 +0200 2005/05/01, Eduardo Robles Elvira wrote: I've added some mid-rule actions, and I get a message like this one: $ bison --verbose -d lea.y lea.y: conflicts: 4 shift/reduce, 3 reduce/reduce lea.y:293.17-40: warning: rule never reduced because of conflicts: @3: /* empty */ lea.y:317.17-40: warning: rule never reduced because of conflicts: @4: /* empty */ lea.y:337.9-31: warning: rule never reduced because of conflicts: @5: /* empty */ If if you want an explanation of what that means, it means exactly what it says, namely, you have entered a grammar which is such that no parser input can cause those rules to be reduced. Normally that is an error in the grammar design. If you enter a mid-rule action, Bison will implement that by introducing an anonymous, empty rule, which thus is prone at generating conflicts, if not used cautiously. -- Hans Aberg ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: Extra code in x.tab.h
At 08:28 +0100 2005/04/30, Rob Desbois wrote: Is it possible to direct bison to insert extra code into x.tab.h - I ask because my %union directive has as one of its members a struct that is defined in a separate header file - ideally this would be included in the generated x.tab.h otherwise I have to make sure it is always included first. I do not think so. It is not as such because one just has to put the right M¤ macro in the skeleton file, and define this macro. But currently, I do not think there is a practical way to do it via Bison. There is an experimental %define command, but it is not currently suitable for entering code. -- Hans Aberg ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: warning: rule never reduced because of conflicts: @3: /* empty */
Please don't forget to cc the Help-Bison list so
others know that your problem is solved.
At 15:10 +0200 2005/05/01, Eduardo Robles Elvira wrote:
El Domingo 01 Mayo 2005 13:22, escribió:
If if you want an explanation of what that means, it means exactly
what it says, namely, you have entered a grammar which is such that
no parser input can cause those rules to be reduced. Normally that is
an error in the grammar design. If you enter a mid-rule action, Bison
will implement that by introducing an anonymous, empty rule, which
thus is prone at generating conflicts, if not used cautiously.
--
Hans Aberg
Thanks for your answer Hans !
I was doing something really stupid, I just hadn't noticed :-). Finally I got
i working, it was a matter of noting where the problem was, as always happen
with silly problems/errors, you see.
Cheers,
Edulix.
--
Hans Aberg
___
Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: Bison Question: Ambiguous Grammar?
At 12:49 +0200 2005/05/06, Claus Brabrand wrote: I have a question about Bisons GLR parser. Is there a way for Bison (in %glr-parser mode) to return a parse tree (doesn't matter which) when parsing according to an ambiguous grammar? Bison never returns a parse tree. If you want that, you need to define its construction in the actions. When people ask that question, they often need much less; if you so want, you may precise your programming situation. -- Hans Aberg ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: Bison Question: Ambiguous Grammar?
At 19:21 +0200 2005/05/06, Claus Brabrand wrote: Yes, I realize there's no parse tree beyond what I may chose to construct in the action code myself. What I meant is: is there a way for Bison to take the actions according to one (any) of the parses? The current Bison GLR parsers work so that when parsing an ambiguous rule, the parser splits, and parses without executing any actions until the ambiguous rule has finished parsing. Then the actions of the successful parses, if any, are executed. There is currently no way to get actions executed immediately, even though Paul Hilfinger, who wrote %glr, is considering this as a feature. I am using Bison in GLR-mode for code-generating syntax-directed transformations (executed in the action code). The grammars are highly ambiguous which is fine: I just want to execute actions for one (any) of the parses. Then you have to choose one of the parses according to the methods indicated in the Bison manual. I do not know if there is a way to avoid actions to be executed in the unwanted parses, if there is more than one successful parses; possibly you have to write the actions, so that they are not harmful in such a case. I have a grammar which is capable of parsing a string (and returning a transformed string which is just the result of executing the corresponding action code). Now, when I add a certain production to this grammar, I get a parse error in the middle of the string it was able to parse without this extra production(?!?) What I don't understand is how adding a production to a grammar G can cause it to reject the string - it should just enlarge the language induced by the grammar - and so, that if it was capable of parsing my string before, it should also be able to do so after (with the extra production). This really puzzles me(?) If the parser constructed all parse trees, that would be the case, but in LALR(1), and scans the rules in order. So then funny things can happen. I do not know if this is the case; you give no details. Also, you might ask this question in the newsgroup comp.compiles, providing the details. Is Bison's GLR algorithm intended for ambiguous grammars or will it only work on the subset of grammars that are unambiguous (LALR(1) or not)? Maybe this particular production renders the grammar ambiguous (at least wrt. my input string - i.e. that my string has two parses). When making this GLR extension, it should work with all ambiguous grammars. The drawback, though, is that it only splits the ambiguous rules, and then merges them when finished. Of one then wants to keep track of all parses, then one will have to do that via the actions. Thus, there is a difference between GLR based on LALR(1) or on LR(1). The advantage of this approach, though, over a genuinely non-deterministic parsing, is that the latter is very slow. -- Hans Aberg ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: Passing filled AST to yyparse() caller after successful parse
At 17:47 -0400 2005/05/07, Jeannot Langlois wrote: In a reentrant GLR parser, how must the yyparse() caller proceed to access the filled AST after a successful parse? I was expecting yyparse() to return a pointer (whose type could be custom-defined by the user just like the yylex() and yyparse() input parameters) to the properly-filled AST, but it seems that this is not the case and the yyparse() return value is only used to return a parse status code. Any ideas or documentation pointers about that? I am not sure the %glr parser currently works in pure mode. Let's cc Paul Hilfinger, who wrote it, to see if he can let us know. -- Hans Aberg ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: reentrant parser - how?
At 23:26 +0200 2005/05/04, Carsten Krueger wrote:
can anybody tell me how this lexer-parser-combination would look if it
is a reentrant parser?
I recall Paul Eggert said that the Bison generated parser, which he
wrote, now is fully pure. If you have some data to be passed to the
parser, that should be done via the arguments to yyparse, and there
are some macros for doing that; see the Bison manual. If yyparse
needs some local data, then there might not be support for doing that
right now. Then you need to figure out how to make the Flex generated
lexer to become pure; for that, check in the Help-Flex list
.
---lexer.l---
%option yylineno
%option case-insensitive
%{
#include "parser.tab.h"
/* hier C-includes*/
%}
%%
.{ return LINE;
}
%%
int yywrap(){ return 1; /* 1: beendet lex */ }
---lexer.l---
---parser.y--
%{
/* hier C-includes*/
%}
%token LINE
%%
PROGRAM : LINE { /* meine C-Anweisung */ }
%%
int yyerror (char const *s)
{
exit(1);
return 0;
}
---parser.y--
---main.c
extern int yyparse();
int main()
{
/* YYIN = file_descriptor_1; */
yyparse();
/* reset_parser - ?? */
/* YYIN = file_descriptor_2; */
/* yyparse(); */
return 0;
}
---main.c
--make.sh
#!/bin/bash
bison -d parser.y
flex lexer.l
gcc -c parser.tab.c
gcc -c lex.yy.c
gcc -c main.c
gcc -o main parser.tab.o lex.yy.o main.o
--make.sh
___
Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: reentrant parser - how?
[Please keep the Help-Bison cc, so that others can help.] At 13:28 +0200 2005/05/08, Carsten Krüger wrote: HA> I recall Paul Eggert said that the Bison generated parser, which he HA> wrote, now is fully pure. Which parser? The C-parser skeleton file. But your subsequent explanations suggests that this is not a question for Paul (sorry). HA> If you have some data to be passed to the HA> parser, that should be done via the arguments to yyparse, and there HA> are some macros for doing that; see the Bison manual. If yyparse HA> needs some local data, then there might not be support for doing that HA> right now. Then you need to figure out how to make the Flex generated HA> lexer to become pure; for that, check in the Help-Flex list HA> . Can you explain it a litte bit more? I do not use a fully pure parser, and I use a C++ parser. So you will have to hope from more input from somebody else. I try to explain my problem. My bison grammar has a BEGIN and an END token and I want to parse many inputfiles consecutively. Example. file1: START some command ... STOP file2: START some command ... STOP Then you do not need fully pure parser. If I use only: yyin=fptr_1; yyparse(); yyin=fptr_2; yyparse(); The second yyparse()-call tells me, START is unexpected. The parser don't know, that the inputfile has changed. This might be usefull for include-files in C, I think. Most likely, this is a problem that the lexer has not been reset. Read the Flex manual, or ask in the Help-Flex list. I use something like "lexer_.initialize(isp_)", but I do not know if that is the original Flex lexer function. The parser function yyparse() will be reset every time it is called anew. It only parses tokens, not streams. -- Hans Aberg ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: Passing filled AST to yyparse() caller after successful parse
At 12:11 -0400 2005/05/08, Jeannot Langlois wrote:
I am not sure the %glr parser currently works in pure mode. Let's cc
Paul Hilfinger, who wrote it, to see if he can let us know.
-- Hans Aberg Hi Hans (and Hi all), Just a few minutes after I
posted the question to the mailing list, I found what I was looking
for. It works. Apparently, when using a reentrant GLR parser, I need
to define an (additional) %parse-param { ... } so I can pass the
resulting AST pointer to yyparse(),
I am aware of this one, but I was not sure if it resulted in a pure
parser. There was a discussion here or in Bug-Bison on some problems
with %glr, but I do not remember exactly it was. -- Error recovery
perhaps.
--
Hans Aberg
___
Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: please help on infix yylex.
At 04:09 + 2005/05/09, Laxman Bana wrote: Lex Gurus, I am trying to learn flex and bison and I started with infix calc example specified in the manual. Everything is nomal when I use yylex() function specified in the manual. But I wanted to generate tokens using flex and I created following rules and it never worked:( I tried to fix this for long time but I am not able to see where I am making a mistake? Please help. I posted 2005/04/01 an example "Simple Flex/Bison example" in this list. See: List-Archive: <http://lists.gnu.org/pipermail/help-bison> -- Hans Aberg ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: Question regarding Bison and Hypermail
At 23:16 + 2005/05/10, Hung Pham wrote: I am trying to install Hypermail and based on the errormessages, I need to install Bison which I did. I then tried to run "make" in Hypermail and here is what I get for the error messages: Expect 13 shift/reduce conflicts. bison -y getdate.y conflicts: 13 shift/reduce *** Signal 13 make: Fatal error: Command failed for target `getdate.c' Current working directory /opt/hypermail-2.2.0/src *** Error code 1 make: Fatal error: Command failed for target `hypermail' I think this has more to do with Bison than it does Hypermail. If anyone has any suggestions, please reply. This is for a project and I am running out of time. I am installing all this on Solaris 9. I think this question has been up here before, and it is a problem in the getdate package, some another GNU software. Contact those who wrote it. -- Hans Aberg ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: About flex source, please help
At 15:31 +0800 2005/05/11, Èêå wrote: Trying to read flex2.5.4 source code, found it's hard to understand, Does anybody have some design document about flex? or have the same interest with me. Maybe we can discuss it. I am not a Flex developer, but I doubt it, because the same question has some up a couple of times about Bison, and there, really nothing is available. The best way might be to read the sources and in books about lexer generator construction. For example, Flex uses a fairly standard two step regular expression -> NFA -> DFA construction. You might also ask in the newsgroup comp.compilers, and checking its FAQ, published there monthly. Also, the latest Flex versions, including CVS, are available at: http://lex.sourceforge.net/ -- Hans Aberg ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: Fwd: Q: processing multiple mixed data streams using bison
At 23:53 -0700 2005/05/28, Mohit Jaggi wrote: Hi All, I am trying to process multiple interleaved streams of data in a single process/thread using yacc/bison. Let us say I am running a server and have thousands of clients sending me requests at the same time. It seems the parser code uses global variables to keep its state while parsing. I guess that one can introduce code to save all the variables and restore them...has anyone tried this before? You do not say what Bison version you are using. I think that the C-parser, by now, is fully pure. There has recently been released a new version Bison 2005/05/23, see List-Archive: <http://lists.gnu.org/pipermail/help-bison> Question about making Flex generating a pure lexer should be directed to: List-Post: <mailto:help-flex@gnu.org> -- Hans Aberg ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: Fwd: Q: processing multiple mixed data streams using bison
Otherwise, I wouldn't said it right? If you pick it down, check the
parser code. I use a C++ parser, and it is not currently pure.
At 11:37 -0700 2005/05/29, Mohit Jaggi wrote:
Hans,
Thanks for the reply...I havn't tried any version yet. Do you think
that the latest version will support this and I won't have to
introduce custom code to save/restore its context?
Mohit.
On 5/29/05, Hans Aberg <[EMAIL PROTECTED]> wrote:
At 23:53 -0700 2005/05/28, Mohit Jaggi wrote:
>Hi All,
>I am trying to process multiple interleaved streams of data in a
>single process/thread using yacc/bison. Let us say I am running a
>server and have thousands of clients sending me requests at the same
>time.
>
>It seems the parser code uses global variables to keep its state while
>parsing. I guess that one can introduce code to save all the variables
>and restore them...has anyone tried this before?
You do not say what Bison version you are using. I think that the
C-parser, by now, is fully pure. There has recently been released a
new version Bison 2005/05/23, see
List-Archive: <http://lists.gnu.org/pipermail/help-bison>
Question about making Flex generating a pure lexer should be directed to:
List-Post: <mailto:help-flex@gnu.org>
--
Hans Aberg
--
Hans Aberg
___
Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: bison 2.0 for windows
I do not know myself, but I have cc'ed the Bug-Bison list, to so it might get the developers attention. The thing is that GNU project are primarily for POSIX, or UNIX like, systems, and all else is extra. But if somebody willing to help making the effort to make such a Windows compile, it will surely be incorporated. At 02:09 +0400 2005/06/08, hz kto wrote: I wanted to get bison 2.0 to make use of %destructor ferature, but there doesn't seem to be support for windows compilation from the looks of the scripts and readme files. Or am I missing something? In readme it says that DOS buils is probably broken right now. Is anybody compiling for windows? thanks in advance Alex ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison -- Hans Aberg ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Output generation
There is a program, Cedric Lemaire, distributed under LGPL, specially designed for generating output from parser actions: http://www.codeworker.org (From the newsgroup comp.compilers, "Re: simple code translator - suggestions?") It might be fit into the context of generating skeleton files, as well as other uses. Guile could though be used to simplify the implementation of new parser algorithms as well. -- Hans Aberg ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: calculator with additional function
At 09:53 +0200 2005/06/10, [EMAIL PROTECTED] wrote: Hi, There was problem with sent my message so I send it again. I need to write calculator with additional function. It have to serve loop FOR where I declare how many times it will run and what will it do inside. My problem is how to bould data structure (it have to be tree) for this calculator. Have You any idea? You have to build a "closure", that can be executed later, building it directly in the actions, in terms of code that can executed after the syntactic termination of the loop. This code can be binary, or an output in some other language that can be compiled and executed later. Most do it directly, by hand, perhaps invoking M4, Guile, or something, as an aid if the output is any other language. Just a few days ago, there has come to my attention the tool <http://www.codeworker.org>, probably useful for more advanced things. -- Hans Aberg ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: Re: calculator with additional function
[Please keep the CC to Help-Bison, so that others may help.] I only use C++. There, in one case, I built polymorphic (virtual) class hierarchy, where the classes have a function evaluate(), which can be called, once the closure has been built. The method of outputting C and then compile it, I think is used by the Haskell <http://haskell.org> compiler GHC. It has also an interpreter, as well as Hugs <http://haskell.org/hugs>. In the latter case, it generates some kind of byte code, which is then passed onto an evaluator engine, which performs the looping. Those are big programs. But you have threshold to step over, anyway. At 14:35 +0200 2005/06/11, [EMAIL PROTECTED] wrote: I can use FLEX and C only. Could you give example of code how it shoud looks? Hi, There was problem with sent my message so I send it again. I need to write calculator with additional function. It have to serve loop FOR where I declare how many times it will run and what will it do inside. My problem is how to bould data structure (it have to be tree) for this calculator. Have You any idea? You have to build a "closure", that can be executed later, building it directly in the actions, in terms of code that can executed after the syntactic termination of the loop. This code can be binary, or an output in some other language that can be compiled and executed later. Most do it directly, by hand, perhaps invoking M4, Guile, or something, as an aid if the output is any other language. Just a few days ago, there has come to my attention the tool <http://www.codeworker.org>, probably useful for more advanced things. -- Hans Aberg -- Hans Aberg ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: Flex/Bison: which version to use?
At 11:28 + 2005/06/13, Frans Englich wrote: For my project, written in C++, I simply downloaded the latest versions(at least at that time); I use Bison 2.0, and Flex 2.5.31. Those are the latest official versions. For Bison, there is a test version 2.0a, you may want to try out, to make sure the next release works for you: ftp://alpha.gnu.org/gnu/bison/bison-2.0a.tar.gz Does it matter what version one uses? What is recommended? For what scenarios does version matter(portability, programming language, functionality, etc)? (if at all) Typically, only the last official version is supported. If you have problems with an earlier version, people helping will not remember those versions, and don't expect there will be bug fix; more likely, it has already been reported and fixed in a later version. If one needs bug fixes, sometimes one may need to pick down the latest alpha or from the CVS. I did that with Flex on Mac OS 10.3.9. Another question; I noticed that I had "flex++" installed, as well as that "bison++" exists, after a quick googling. Are those "++" versions established software which people use? What are their advantages? When should I need to think about whether I should use the "++" programs? Those are independent programs, supposedly old. Bison and Flex do not have anything with them to do, what I know. -- Hans Aberg ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: "Eating" comments: not with Flex but with Bison
At 20:46 + 2005/06/13, Frans Englich wrote: I think I have a special scenario wrt. to comment handling: in one version of my language, comments are allowed while in another it is not. Hence, depending on version I want to flag the existence of comments as syntax errors, regardless of whether they are valid. You could try to set a context switch in the lexer (see the Flex manual, "start conditions") on the comment lexing rule(s). Then this context switch can be turned on/off in various ways. For example, the lexer could be initiated (right after %% in the .l file) with checking a global variable doing this. This variable can be turned on/off from the parser. -- Hans Aberg ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: Interpreting shift/reduce conflicts from .output file
At 17:05 + 2005/06/15, Frans Englich wrote: > >72 SequenceType: ItemType . >73 | ItemType . STAR >74 | ItemType . PLUS >75 | ItemType . QUESTION_MARK > > PLUS shift, and go to state 134 > STAR shift, and go to state 135 > QUESTION_MARK shift, and go to state 136 > > PLUS [reduce using rule 72 (SequenceType)] > STAR [reduce using rule 72 (SequenceType)] > > $default reduce using rule 72 (SequenceType) The precedence shift/reduce resolving system works so that it looks at the token immediately before the "." in the reduce rule, and the token immediately after the "." in the shift rule, and use the defined token precedences (%left, etc.) to make a choice. If your rules are not on this simple form, it will not work. So then you may decide to rewrite your grammar. -- Hans Aberg ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: "nested" languages
At 11:40 +1000 2005/06/28, Neil Conway wrote: I'm trying to use Bison to construct a parser for a language A that needs to allow syntax from a second language B to be embedded within it (at well-defined positions within A). For example, suppose a production from the grammar of A is: if_stmt: IF expr THEN if_body END IF ; where "expr" is a production in *another* Bison grammar. Language B is defined by a fairly complex grammar that changes with some regularity (in this case, the embedded language B is SQL, defined by an ~8500 line bison grammar). B's grammar is maintained separately -- merging B's grammar into the grammar for A and maintaining two copies is a headache I'd like to avoid, if possible. Ideally I'd like to have A's parser "call into" B's parser, have it accept as much input as it can, and then return control to A's parser. Is this possible? One idea would be to use hand-written parsers for both languages, although it would be nice to stick with Bison if possible. Bison only one single .y file as input, and must be presented such a file. One way to do it, might to use a preprocessor (Perl, M4 perhaps) so merge the files. The problem might be, though, that the combined grammar isn't LALR(1) anymore. (At present this is implemented by having the lexer look for a delimiter in the input that we know marks the end of the tokens of the embedded language. We then concatenate these tokens into a string, and eventually pass that string to the yyparse() of the embedded language's parser. So in the above example we would basically consume tokens until we see a "THEN", and assume that anything between the "IF" and the "THEN" is a SQL statement. This is ugly, to say the least.) There are a few methods in use to combine grammars. One is to merge grammars together, as you suggested. Another is what you already is using. Sometimes, one is using a hybrid: If one has a large number dynamic operator precedences, as in Prolog for example, then it is not really feasible to write that into a large Bison's grammar directly. So one would a small grammar, putting the operators on a stack, and then let a sort out the precedences in the actions. If the number of precedence is small, as Haskell, which only has ten levels, one could write it in directly in a static grammar, though. There, some do it, others use the first method. In general, no method is better than the other; in the specific case, one chooses the one most convenient, simply. You might also get more inputs on this question in the newsgroup comp.compilers. -- Hans Aberg ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: %union, C++, symbol types
On 6 Jul 2005, at 11:40, Evan Lavelle wrote: I'd like to pass a token class from Flex to Bison (ideally, a tr1::shared_ptr - a reference counted smart pointer class). However, in Bison itself I need to deal with a number of symbol types - tokens, AST nodes, and so on. This means that I need to use a %union, but this is difficult because the classes are too complex to put in a union. Using class pointers in the union is difficult, because this messes up the reference counting, and I have to do manual resource management. You do not need to use %union. I use a C++ polymorphic (virtual) hierarchy together with dynamic_cast; any eventual type errors will then be revealed at runtime. (In addition, I found it useful to add a Std::string and a integral type to my YYSTYPE, used only to forward token names and numbers to the Bison parser.) You can also use static_cast, as dynamic_cast is slow (just as any dynamic allocation), if your class hierarchy aren't marked "virtual" in the derivation. Then, one would probably need Bison's static type checking. This can easily be done, as soon Bison gets suitable constructs (like %typed, not requiring a union for implementation, and %code which admits proper code placement). But it cannot handle it right now. Also try out latest Bison alpha <ftp://alpha.gnu.org/gnu/bison/ bison-2.0a.tar.gz>; it should be more reliable than the version you are using. Hans Aberg ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: Flex: token value more than what regexp matches
On 7 Jul 2005, at 23:53, Frans Englich wrote:
I have the problem that the value of a token appears to be more
than what the
regexp matches.
When parsing the expression "fn:false()", I get a QNAME token with
the value
"fn:false" -- what I expect & want.
However, when parsing the expression "false()", I get the token
NCNAME with
the value "false(". The token is right, but I don't want the
parantese to be
included.
This is frequently asked question: The Flex lexer merely provides a
pointer to the identified text in a buffer, temporarily '0'-
terminated, and in order to preserve that in subsequent lexer calls,
you need to copy it over. The Bison parser does indeed make several
calls to the lexer before the rule action is invoked.
Hans Aberg
___
Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: %union, C++, symbol types
typedef formula_null null_type;
clone_declare(formula) = 0;
copy_declare(formula) = 0;
...
};
class T_null : public T {
public:
clone_declare(formula_null);
copy_declare(formula_null);
...
};
Two points: If one wants to use static_cast, instead of dynamic_cast,
then the base classes cannot be virtual in derivation. And the class
T_null above is used to implement special behavior of ref().
Hans Aberg
___
Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: Lexical feedback and lookahead
On 19 Jul 2005, at 17:01, Evan Lavelle wrote:
The problem is, in my input, there aren't *any* context-independent
keywords (not in this case, anyway). This is equivalent to the
COBOL problem where FUNCTION is optional. The grammar looks like this:
program : function_list ;
function_list
: /* nothing */
| function_list function ;
function : { recognise_function_names = true; }
valid_function '{' function_body '}' ;
valid_function : FOO | BAR ;
The only way that I know a new function is coming up is that an
existing function has just completed: there's no convenient keyword
to give me warning. [If my grammar really was this simple, then I
could probably use another token to recognise the end of a
function, but the real input is pretty complex].
It seems me that you know that a function has been completed when the
function body top level "{" ... "}" has completed. This can be kept
track of by a bracket depth count in the lexer.
Any ideas? It seems to me that I need an 'unget' implementation.
In Bison, it is called %glr.
Hans Aberg
___
Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: [help-bison]How to stock information?
On 19 Jul 2005, at 17:39, soledady wrote:
if you receive for twice time this message i'm sorry i made a mistake
It it did come twice; I reply to the second address. [Please keep the
cc to Help-Bison in replies, so that others can help.]
Hello, i'm using Bison for compute a mathematic tool to resolve this
kind of thing:
u(n)=u(n-1)+3*u(n-2);u{0}=1;u{1}=2;
the example is very simple and this tools can do more things
So the subject:
when I execute bison It builds a syntaxical tree (doesn't it?)
Not really. Bison supplies the constructs so that you can build a
syntax trees in the parser, bottom up, if you so want. One can't
immediately build them top-down.
For example, if you have a rule
term:
term "+" term {...}
then $1, $2, and $3 will be used to assign values to the RHS
occurrences of "term", which can be forwarded to the LHS by the use
of $$. If you let $$ be the root of a tree, and $1, $2 and $3 be
branches attached to $$, you get a syntax tree:
$$
/ | \
$1 $2 $3
how recover number (they could change of course) in a correct order
cause i need to know how the formulation is written..
i give you a parse of the code: (the print are just here in order
for me
to understand how does it works)
g:'=' d g{printf("=");}
|U '{'N '}' g{printf("U{N}");}
|U '{ N '-'NB'}'g {printf("U{n-%d}",$5);}
|U '{' N '+' NB '}' g {printf("U{N+%d}",$5);}
|U '{' NB '}' g{printf("U{%d}",$3);}
|d g{printf(" ");}
|V g{printf(" ");}
|/*empty*/{printf(" ")}
d:g T {printf(" ");}
|NB ';'{printf(" %d ",$1);}
T:/*vide*/{printf(" ");}
|NB T{printf("%d",$1);}
|'*' T{printf("*");}
|'/' T{printf("/");}
|'^' T{printf("^");}
|'+' T{printf("+");}
|'-' T{printf("-");}
|';' T{printf(";");}
so for this part of an example (without all the rest of the example)
U{N}=U{N-1}+3*U{N-2}; U{0}=1; U{1}=2;
it's give me:
*3+; 1 2 =U{1}=U{0} U{n-2} U{n-1}=U{N}
how can i do to recover correctly which number for which part of
code ?
My guess is that you ask for the semantic value. It will be held in
the variables $$ and $k.
more precisely i need to generate code in java and to do that i need
which kind of fomulation its given?
My guess is that you want to write Java code to later be executed.
Then you could write actions that output say strings for use in M4,
or Guile, which would generate the Java output. It something similar
for a program writing code in C++, and then it turned out to be
tricky to place various C++ constructs, such as #include without at
least a macro program. M4 is though tricky to use, therefore Guile
might be better.
Also, there is a program <http://codeworker.free.fr/> dedicated to
this kind of task, you may want to have a look at.
thanks for your help!
if you need more precision let's continue:
moreover it's inside of a group of result globaly like that
for this code:the indentation are here just to be clearer
begin
Name=Suite;
begin
DEFINITION=RECURRENTE;
U{N}=U{N-1}+3*U{N-2};
U{0}=1;
U{1}=2;
TERME[1..8];
VARIATION;
TYPE;
SI_ARITH
begin
FORMULE_ARITH;
SOMME_ARITH[1..8];
end
SI_GEO
begin
FORMULE_GEO;
SOMME_GEO[1..8];
end
end
end
i'have this tree (the printf("blabla"); ) the indentation are here
just
to be clearer
You just assign the suitable text values to the tokens, and start to
build suitable strings or macros. Assume you have
statement:
"{" statement_body "}"
statement_body: /* Builds "u(n)=u(n-1)+3*u(n-2);u{0}=1;u{1}=2;" */
Then you need an action for "statement" like
statement: "{" statement_body "}" {
$$ = "begin Name=Suite; begin DEFINITION=RECURRENTE;" + $1 + ...
}
where "+" is string concatenation. I hope you see the idea.
You can simplify token handling by using Flex, and let every token
return the text that is lexed.
Hans Aberg
___
Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: [help-bison]How to stock information?
On 20 Jul 2005, at 07:49, soledady wrote:
can i construct a top-down grammar?
It isn't the grammar that is top-down or not -- it is the parse tree
that one build. The Bison generated parser builds it bottom-up,
because Bison uses LALR(1). The other method is LL(k). In Bison, one
sometimes has to introduce a global variable, which carries some
semantic information. That is essentially a top-down construct.
For example, if you have a rule
term:
term "+" term {...}
then $1, $2, and $3 will be used to assign values to the RHS
occurrences of "term", which can be forwarded to the LHS by the use
of $$. If you let $$ be the root of a tree, and $1, $2 and $3 be
branches attached to $$, you get a syntax tree:
$$
/ | \
$1 $2 $3
the $$ could be use again in other rule couldn't it?
Every rule and token has its own semantic value, represented locally
in the rule actions by the symbol $$.
just a precision what the meaning of RHS and LHS(Right...? and Left
something?)
See
http://en.wikipedia.org/wiki/LHS
http://en.wikipedia.org/wiki/RHS
so for this part of an example (without all the rest of the example)
U{N}=U{N-1}+3*U{N-2}; U{0}=1; U{1}=2;
it's give me:
*3+; 1 2 =U{1}=U{0} U{n-2} U{n-1}=U{N}
how can i do to recover correctly which number for which part of
code ?
My guess is that you ask for the semantic value. It will be held in
the variables $$ and $k.
ok but how can i do to know that *3+ means +3*
and to know which kind of term (u(n) or u(n+1) and so on...) are in
use
Yo define a grammar, just as you already have started, and then in
each action you have the input semantic values $1, $2, ..., $k, where
k is the rule length, and then you use them to define a value of $$.
Bison generates a parser that makes sure that his hangs together.
statement:
"{" statement_body "}"
statement_body: /* Builds "u(n)=u(n-1)+3*u(n-2);u{0}=1;u{1}=2;" */
yes but how can i built this expression
You have to build a grammar. This is difficult at firts. The Bison
manual has a calculator example. The book by Aho, Sethi, Ullman,
"Compilers" (the "dragon book") has an example of using Lex and Yacc.
Look in grammar-like BNF notation of already existing computer
languages, as that of the C/C++ standards. The newsgroup
comp.compilers has a FAQ, published there monthly, which you can look
into.
Hans Aberg
___
Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: Lexical feedback and lookahead
On 20 Jul 2005, at 09:21, Evan Lavelle wrote:
It seems me that you know that a function has been completed when
the function body top level "{" ... "}" has completed. This can
be kept track of by a bracket depth count in the lexer.
Unfortunately, the real grammar is much more complex and counting
brackets normally isn't adequate. Besides, if I could do this, it
would be easier just to use start states in the lexer: I need
StartStates++, which is lexical feedback from the parser.
Only you can decide what method works best for you.
Any ideas? It seems to me that I need an 'unget' implementation.
In Bison, it is called %glr.
They don't do the same thing. Feedback, if it worked, could be used
as a general solution to eliminate keywords.
If you want something like that, I guess you will have work out how
it should be implemented into Bison. The parser isn't easy to tweak.
It stacks states, not tokens, so you will have to reverse that process.
GLR/unlimited lookahead could, in principle, do the same thing, but
it's much less general, much less efficient, and it's more
difficult to design the language in the first place. Consider this
pseudo-grammar:
top : keywords_top ;
keywords_top : lots_of_keywords | NAME ;
keyword1 : more_keywords | NAME ;
keyword2 : even_more_keywords | NAME ;
...
How do you do this in GLR? It's trivial with working feedback, and
you can recycle keywords at different levels of the grammar.
I am not sure what you are saying here. You should just plug it in,
and then you will have to merge some actions at suitable places. The
point with GLR, relative pother forms of non-deterministic parsing,
is that it is fairly efficient, as it merges parse splits as soon as
possible. I haven't used it, though, so some other fellow will have
to help yu on more details.
I had a grammar, where the two methods I indicated came up: EIther
use a context sensitive switch, and within that use bracket depth or
some tweak like that. Or the alternative would have been to use GLR.
But as it happened, I made a different grammar, where these
constructs are no longer present, though the question may arise again.
You may also ask in the newsgroup comp.compilers for more inputs.
Hans Aberg
___
Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: [help-bison]How to stock information?
On 20 Jul 2005, at 23:06, alfonso wrote: This reminds me of a gripe I had when learning to use Bison (not that I'm an exper or anything, but I know enough to use it) - the calculator example in the docs is so trivial that it is completely worthless, and the existing language grammars such as C and C++ (good lord) are way too complex for the purposes of learning Bison. I'd really like to see a language with about 10 or 15 keywords written as an example. Granted, I know the answer - if I want to see it, I should write it myself, but who has time for documentation ;) You don't use the whole grammars of say C++, but only selected subparts, say for the type of expressions that you want. Don't try to copy the C++ informal grammar-like stuff, because you will get into trouble; just use it as an inspiration. Hans Aberg ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: Need Help in Shift Reduce Errors
On 22 Jul 2005, at 06:23, Atul Kulkarni wrote: I am facing a problem with the Grammar i am feeding to the Bison. It throws 2 shift reduce conflicts. Please help with this I am not able to resolve them. Shift/reduce conflicts can sometimes be resolved using token precedences (%left, etc.). Look into the .output file, in the states with the conflict, and there, at the conflicting rules. Set token precedences for the tokens immediately before and after the ".". If there are no such tokens, the best option for this method to work, is to rewrite the grammar, as to get them. Hans Aberg ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: Need help in Bison with Unicode
On 23 Jul 2005, at 09:41, Hieu Le Trung wrote: Hi have a project that use bison to parse some file. I need to change to Unicode version and I don't know does bison support Unicode or not? The Bison generated parses token, so from that point of view, it is a non-issue. You cannot though use the token character forms '...' for Unicode characters. Instead use standard tokens "%token ...". As for the error messages that the Bison writes, at least those in English, these are in the ASCII 7-bit byte subset. If you need error messages in other languages, you could use UTF-8. The problem is mostly with the lexer. I have started to use Flex, by merely writing the .l file in UTF-8 in the "..." patterns, thus generating a UTF-8 lexer, and it seems to work (which it should, unless there some unforeseen snag to it). I have also, in the flex list, posted a Haskell program, by which one can generate Flex like regular expressions from Unicode character classes. I think there might be Flex support for Unicode, but I do not know how this work progresses. Hans Aberg ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: can we generate a C++ parser with Bison?
On 27 Jul 2005, at 06:58, Sheng Wang wrote: Since Bison 2.0 can generate GLR parser, can we use this feature to get a C++ parser that can correctly parse C++ programs that conform to the ISO standard? There is an example in the Bison manual on how some of the C++ ambiguities can be resolved using GLR. If you want a Yacc-like C++ grammar, see http://www.parashift.com/c++-faq-lite/compiler- dependencies.html#faq-38.11 More general info about compiler construction can be found in he Usenet newsgroup comp.compilers and the FAQ published there monthly. Hans Aberg ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: $1 is not $1 but $1+$2
On 29 Jul 2005, at 10:53, Gianni Pucciani wrote: the value in $1 is not that retrieved by the rule dbname. What happens is that in that rule, the value of $1 is not "$$ of dbname rule" but $1 + $2 , that is the two strings "dbname tablelist" concatenated. In other words, in the passage from one rule to another, the value of dbname is lost. Any advice? Check the FAQ: http://www.gnu.org/software/bison/manual/html_mono/ bison.html#Strings-are-Destroyed Hans Aberg ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: Which one is "better" ?
On 31 Jul 2005, at 01:07, Baldurien (club internet) wrote: I have a grammar to do for my self, and since this grammar add the same expression than the one we could have in a SQL query language, I'm wondering which grammar is better in term of performance. My first one is the classical "one production per precedence" : ... With %left, and %nonassoc (and %right too) it give this : There is no big practical difference between these two methods, as a typical compiler spends most time in the actions and the lexer. So choose the method you are most comfortable with. Using precedence rules %left, etc. produces a more compact grammar that is also more structured, which might help human programming. Otherwise, using precedence rules cuts down the number of states, so that parser will be somewhat faster; the transitions, independent of number, are put in a lookup array, so the number does not affect parser size. Hans Aberg ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: Re[2]: Which one is "better" ?
On 31 Jul 2005, at 18:03, Baldurien (club internet) wrote: Now, I'm asking myself about how bison store the grammar in the produced parser : In class I've seen how to construct the LL(1) table, and the transition table for the automata, but since I've seen it only on paper, I don't know how I could efficently store this like Bison does ? Bison is currently only supporting LALR(1), which is essentially a cut down and compacted form of LR(1). This is described in standard books on compliers, for example, the one by Aho et al. "Compiler..." (the "dragon book"). You might look into the book by Dick Grune, available online (see the FAQ of the newsgroup comp.compilers, published there monthly). In short, the grammar isn't stored at all in the parser, only the states one sees in the ".output" file. Hans Aberg ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: Implicit Multiplication
On 6 Aug 2005, at 03:05, Aaron Hurst wrote:
I'm trying to parse a simple algebraic (Boolean) expression using
the grammar described below. However, I would like to be able to
parse implicit multiplication (i.e. if two expression appear next
to each other without an operator, they should be mulitplied).
I once wrote such a grammar, but I concluded that in a computer
program, the effort of refining the grammr does not seem worth the
effort.
For example,
a b + (c + d)g
should parse the same as
a * b + (c + d) * g
As written below, there are several shift/reduce conflicts caused
by the last rule (the implicit multiplication). I have no idea how
to rewrite this unambiguously.
%left '|' '+'
%left '^'
%left '&' '*'
%nonassoc '\''
%nonassoc '!'
expression:
IDENTIFIER
| '(' expression ')'
| expression '*' expression
| expression '&' expression
| expression '+' expression
| expression '|' expression
| expression '^' expression
| '!' expression
| expression '\''
| expression expression %prec '*' /* this rule causes problems */
;
By your last rule, for example a + b c + d becomes ambiguous, as it
admits the interpretations (a + b) (c + d) and a + (b c) + d.
Grammatically, implicit multiplication only applies to certain
situations, where one of the operands is an identifier, a constant,
or enclosed in parenthesizes. The precedences, %prec '*', only apply
to tokens, and you have none in that rule.
Hans Aberg
___
Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: Implicit Multiplication
On 6 Aug 2005, at 03:05, Aaron Hurst wrote:
I would like to be able to parse implicit multiplication (i.e. if
two expression appear next to each other without an operator, they
should be mulitplied).
Here is a variation:
%token IDENTIFIER
%left '|' '+'
%left '^'
%left '&' '*' IDENTIFIER '(' ')'
%%
expression:
IDENTIFIER
| '(' expression ')'
| expression '*' expression
| expression '&' expression
| expression '+' expression
| expression '|' expression
| expression '^' expression
| IDENTIFIER IDENTIFIER
| IDENTIFIER '(' expression ')'
| '(' expression ')' IDENTIFIER
| '(' expression ')' '(' expression ')'
;
Hans Aberg
___
Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: Implicit Multiplication
On 9 Aug 2005, at 01:33, Aaron Hurst wrote:
This seems to implement exactly the behavior I was describing. The
help is much appreciated.
You are welcome. But you need to check the token precedences for
IDENTIFIER '(' ')'; I just put them in to avoid conflicts. [Also keep
the cc to Help-Bison, so others know.]
Hans Aberg
___
Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: classical error but unresolved "syntax error at end of input"
On 9 Aug 2005, at 17:23, soledady wrote: the result of the grammar file (*.y) compilation give me this error: "syntax error at end of input" You do not give much information, such as which Bison version you use. You could try adding ";" after each grammar rule. Perhaps you should make a bug report to Bug-Bison. Hans Aberg ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: problem with $$, maybe bug??
On 10 Aug 2005, at 21:18, Roberto Mandall wrote:
hi there, i´m using last version of bison on windows xp., bison 1.875
i have come up with a problem which is just dirving my crazy, see
the code here:
function_designator : identifier {
dir=BuscarSimb(TablaActual,$1,
&veces);
$$=malloc(sizeof(struct RecordGCI));
$$->tipo=dir->tipo;
$$->texto=malloc(strlen($1)+1);
$$->texto=strcpy($$->texto,$1);
$$->tiporet=dir->tipo_retorno;
$$->numparam=dir->n_param;
strcpy(nomfungu,$1);
nodolistaauxiliar.paramlleva=numparamllevo;
nodolistaauxiliar.parammax=numparamreal;
nodolistaauxiliar.sigparam=puntiparam;
nodolistaauxiliar.ptrbu=$$;
strcpy(nodolistaauxiliar.nomfun,nomfungu);
Insert1(nodolistaauxiliar,listaauxiliar);
numparamllevo=0;
CuantosNormal++;
FunDesigIden();
}
params {
FunDesigParams($$);
};
ok, so the big problem is that after params , when calling
FunDesigParams($$),
the pointer has changed its value but i can assure you that i do not
touch that $$ any other place but here, and still do not change it at
that Macro(fundesigparams)
In the $$ value of the first action is named $2 in the last action.
Is that your problem?
Hans Aberg
___
Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: question
On 14 Aug 2005, at 06:15, David Ja wrote: I been trying to adapted bison to my own purpose but after a month of trying I can't seem to figure out a way to make it work. All I wanted to do was to take advantage of bison's parser which generates the DFA, Bison does not generate a DFA, but uses the LALR(1) algorithm to generate a push-down automaton. Flex does generate a DFA. which in turn, allows me to step through the DFA in sequence generating a sample string that fits the grammar input. For example if the grammar is the grammar for an web address. My program will be able to generate http://www.abc.org<http://www.abc.org>. It seems that you attempt to do some kind of pretty-printing, which is the opposite of what tools like Bison and Flex do. A parser translates one computer language to another. So if you feed it with one string, it will produce another (which might be some binary code). Hans Aberg ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
