Re: Bison 3.0.5

Akim Demaille wrote: > I think Bison 3.0.5 is ready. However, before making it widely > available it would be nice if people could give it a try on their > projects. I've tested it with my C++17 skeletons dropped in and it worked as expected. Regards, Frank

Re: %destructor feedback

Joel E. Denny wrote: > On Sat, 22 Oct 2005, Frank Heckenbach wrote: > > > Joel E. Denny wrote: > > > >> On Fri, 21 Oct 2005, Frank Heckenbach wrote: > >> > >>> Akim Demaille wrote: > >>> > >>>> Maybe that does not deser

Re: %destructor feedback

Joel E. Denny wrote: > On Fri, 21 Oct 2005, Frank Heckenbach wrote: > > > Akim Demaille wrote: > > > >> Maybe that does not deserve that much attention: it seems pretty weird > >> not to use a value. A warning seems a better feature. > > > > I so

Re: %destructor feedback

you go for the warning, could you please make it optional? (I think it would be a useful feature in general, including several of my grammars, but in some cases I'd probably prefer to turn it off.) Frank -- Frank Heckenbach, [EMAIL PROTECTED] http://fjf.gnu.de/ GnuPG and PGP keys: http:/

Re: problem linking program containing bison-generated parser

ed a complex lexer from manual to flex, and though I added some more special cases etc., the resulting flex code was shorter and more readable. So I'm interested why you find the manual way easier. Frank -- Frank Heckenbach, [EMAIL PROTECTED] http://fjf.gnu.de/ GnuPG and PGP keys: http://fjf

Re: x + (y) + z

m from my side. I don't know if your changes are considered non-trivial enough to require an assignment as well, and I don't know if any bison maintainers are reading this here. Otherwise you might want to post it to bug-bison, possibly already as a diff to the texinfo file with acc

Re: x + (y) + z

ast two are required? All the involved (top-level) rules must have a `%merge'. In the original example, both happened to be the same rule. The second example works and shows all four trees (after fixing a few precedences in the grammar) with another `%merge' -- in the final grammar you m

Re: x + (y) + z

our grammar is different and it doesn't work for you, it might help to post the relevant parts of your actual grammar. Frank -- Frank Heckenbach, [EMAIL PROTECTED] http://fjf.gnu.de/ GnuPG and PGP keys: http://fjf.gnu.de/plan (7977168E) ambiguity.y Description: Binary data

Re: x + (y) + z

). Have you looked at `%merge'? Frank -- Frank Heckenbach, [EMAIL PROTECTED] http://fjf.gnu.de/ GnuPG and PGP keys: http://fjf.gnu.de/plan (7977168E) ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison

Re: x + (y) + z

arsed. My %gooa option proposal > avoids this grammar violence. If I understand your previous mails correctly, it doesn't. It may make the cases where you need to rewrite less common, but it's not clear that this makes your code any simpler (as you write it once, no matter how of

Re: x + (y) + z

HO not a very good one, if you can't use the parser the way it's supposed to. But since you don't state why you don't do the usual thing (separate token for type names), I can't say anything more ... Frank -- Frank Heckenbach, [EMAIL PROTECTED] http://fjf.gnu.de/ GnuP

Re: x + (y) + z

erent token for type names which disambiguates declarations as well as this case. Frank -- Frank Heckenbach, [EMAIL PROTECTED] http://fjf.gnu.de/ GnuPG and PGP keys: http://fjf.gnu.de/plan (7977168E) ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison

Re: Forcing multiple parse stacks to 'reduce'

ely, end-of-grammar) token to signal the end of input (of one "grammar", i.e. one statement in your case). So you'd have to supply this token, which is exactly the problem you're having ... Frank -- Frank Heckenbach, [EMAIL PROTECTED] http://fjf.gnu.de/ GnuPG and PGP keys: h