Passing additional parameters to %merge function
Hello, I am using the %parse-param option of bison to pass additional parameters to the parse function. I pass a pointer to an instance of a class which holds the parser environment (because i'm using %pure-parser) I am also using the %glr-parser option and I use %merge to merge the parsers. However I cannot find a way to pass the additional parameter to the %merge function and I need the parser environment in the merging function. Currently I "solve" this by making a global variable, but this is ofcourse not good since it defies the purpose of a pure parser Regards, Michel ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Question about "Conditions for Using Bison" in Bison 2.0 documentation
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
Passing parameter to `merge' function
I deleted the message asking about passing a parameter to the `merge' function, so I can't reply directly. There may be a better way of doing this, but a workaround might be to use thread-specific information, assuming each call to `yyparse()' has its own parameter object and each parameter object is associated with a single call to `yyparse()'. With some care, it might be possible to use thread-specific information even if these conditions don't apply. However, I neither know how the merge facility works, nor how it would interact with threads. If you're using LinuxThreads (which is included in the GNU Standard Library for C), see the man page for `pthread_getspecific'. I believe it should also be possible to use a different library that implements POSIX threads, though. If you want to see an example of using thread-specific information, my code is available at http://savannah.gnu.org/cgi-bin/viewcvs/3dldf/3dldf/Group/CWEB/ I define `struct Thread_Info_Type' in the file `pspglb.web'. Otherwise, I recommend David Butenhof's book _Programming with POSIX Threads_. Laurence Finston http://www.gnu.org/software/3dldf/LDF.html ___ 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
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
Ambiguity involving two parse stacks reducing on the same rule
All, I had misunderstood how %merge worked and was trying to solve a problem by using %dprec and grammar rewrites. Frank Heckenbach came up with the following grammar which highlights the issue very well (I had assumed that %merge would only be applicable when two different grammar rules were involved). You might like to consider the following text (or something like it) for inclusion in the Bison manual (credit to Frank for such a minimalist grammar). - It is possible for a grammar to contain an ambiguity that is only recognised as such when two glr parse stacks attempt to reduce through the same rule. For instance, given the grammar: %% v: e | e e e: 'a' | 'a' 'a' the input "aaa" could be parsed as either e -> 'a' 'a' e -> 'a' v -> e e or as e -> 'a' e -> 'a' 'a' v -> e e Adding a %merge to the second production involving v removes the parse stack resolution ambiguity (or at least passes it off to a user supplied function). This ambiguity cannot be resolved using %dprec because at the point it occurs only one rule is under consideration by both parse stacks. derek -- Derek M Jones tel: +44 (0) 1252 520 667 Knowledge Software Ltd mailto:[EMAIL PROTECTED] Applications Standards Conformance Testing http://www.knosof.co.uk ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
