Re: how to solve this reduce/reduce conflict?
On 22/09/2022 21:34, Derek Clegg wrote: This is horrid, and not how math works. Spaces necessarily mean nothing, and imbuing them with meaning is nonsense. Please reconsider your grammar. It's a programming language, not maths. There are, of course, languages in which spaces necessarily mean something. But I can't bring myself to use any of them. I don't like it, but chacun a son gout.
Re: Resolving shift/reduce conflicts?
I don't know how familiar you are with this, so apologies if I'm stating
the obvious.
General observations:
1 - start by writing a skeleton with no actions; this makes it easier to
find conflicts. When you're done, add the actions
2 - this is *way*, *way* too verbose. You don't need tokens for ';',
'{', '}', etc - just write them explicitly in the description; this
makes it much easier to read. Get rid of all the $$. Move all the
common body actions out to routines at the bottom of the file, etc.
yyGetParser->SetCurrentCombine("") is just noise.
3 - if you have an optional ';' in your description, try not to repeat
the body twice, once with a ';', and once without:
MethodDeclaration
: MethodHeader jp_SEMICOL
| MethodHeader MethodBody
| MethodHeader MethodBody jp_SEMICOL
this is asking for conflicts, and is too verbose. Try (4) for the
conflicts, and/or this to reduce verbosity:
MethodDeclaration
: MethodHeader jp_SEMICOL
| MethodHeader MethodBody opt_semicolon
See also ConstructorDeclaration, etc.
4 - I think your fundamental problem is that your semicolon handling is
too complicated; I'm surprised that you only have 4 conflicts. Statement
terminators are always difficult. My procedure is to move this to the
top level, as far as possible. I can't easily explain why, but this does
seem to make it much easier to write without conflicts (and to handle
error recovery). If you're lucky, you end up with something like this,
with no other terminators in your description:
statement
: statement_a ';'
| statement_b ';'
| statement_c ';'
| /* empty */ ';'
| ...
;
5 - turn the counter examples into real source code that demonstrates
the problem - that makes it much easier for us to see the issue, and may
make the resolution clearer.
Re: Bison 3.5.1 released
Ubuntu 16 (gcc 5.4.0): Ok SLES 12 (gcc 4.8.5): Ok RHEL 7.7 (gcc 4.8.5): Ok All report the bison version as 3.5.3.3-6e89b when run. On 02/04/2020 10:53, Evan Lavelle wrote: > Hi Akim - yes, that builds cleanly (with no warnings) on Scientific > Linux 6.10 (an RHEL 6.10 clone), with a default configure (with '--prefix'). > > I'll run up some KVMs tonight (GMT+1) and try them, but they're on newer > gcc versions (RHEL7/SLES12 4.8.5, Ubuntu16 5.4.0). > > Thanks. > > > On 02/04/2020 06:30, Akim Demaille wrote: >> Hi, >> >>> Le 1 avr. 2020 à 10:12, Evan Lavelle a écrit : >>> >>> Great - thank you. >> >> Could you please try these? >> >> https://www.lrde.epita.fr/~akim/private/bison/bison-3.5.3.3-6e89b.tar.gz >> https://www.lrde.epita.fr/~akim/private/bison/bison-3.5.3.3-6e89b.tar.xz >> >> If it addresses your concern, I'll release 3.5.4. >> > >
Re: Bison 3.5.1 released
Hi Akim - yes, that builds cleanly (with no warnings) on Scientific Linux 6.10 (an RHEL 6.10 clone), with a default configure (with '--prefix'). I'll run up some KVMs tonight (GMT+1) and try them, but they're on newer gcc versions (RHEL7/SLES12 4.8.5, Ubuntu16 5.4.0). Thanks. On 02/04/2020 06:30, Akim Demaille wrote: > Hi, > >> Le 1 avr. 2020 à 10:12, Evan Lavelle a écrit : >> >> Great - thank you. > > Could you please try these? > > https://www.lrde.epita.fr/~akim/private/bison/bison-3.5.3.3-6e89b.tar.gz > https://www.lrde.epita.fr/~akim/private/bison/bison-3.5.3.3-6e89b.tar.xz > > If it addresses your concern, I'll release 3.5.4. >
Re: Bison 3.5.1 released
Great - thank you. On 01/04/2020 07:20, Akim Demaille wrote: > Hi, > >> Le 31 mars 2020 à 21:05, EML a écrit : >> >> This doesn't compile on RHEL 6.10/gcc 4.4.7, with "#pragma GCC >> diagnostic not allowed inside functions". I've 'fixed' this with the >> hack at https://trac.macports.org/ticket/59927. > > Why on earth this was never reported before??? This is _bad_ > (and I'm thinking other words). > > Distros should not keep bugs for themselves. That even worse > for tools such as Bison, that generate code which is expected > to be portable. > > I'll have to make things clear on MacPorts, thanks! > >> Is this known about/intended? I get the impression from >> https://lists.gnu.org/archive/html/bug-bison/2019-10/msg00061.html that > > No, it is *not* know. Otherwise it would have been fixed. > If you follow the thread you pointed to, we fixed what we > could see. > > I'll work out a fix and keep you informed, thanks! > >
Build problems
Ubuntu 14.04, building 2.4.1 from source (yes, I know 2.4.1 is old, but (1) at least appears to be just a config problem): 1 - Can't make bison.texinfo, with makeinfo/texinfo installed (can avoid by preventing a docs and examples build by modifying docs/Makefile and examples/Makefile) 2 - when configured with '--prefix=/home/me/local', the 'location.cc' (and presumably skeleton) file used is actually /usr/local/share/bison/location.cc, and not /home/me/local/share/bison/location.cc. ___ help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison
'yylval was not declared' on switch from Bison 2.4.1 to 3.0.2
Any idea how to fix this? I have a grammar which compiled without problems on bison 2.4.1/gcc 4.4.7 (RHEL 6.5), but which won't now compile on bison 3.0.2/gcc 4.8.2 (Ubuntu 14.04). The bison.tab.cc output from 2.4.1 included a definition of yylval as: semantic_type yylval; The 3.0.2 output has no definition, and the compiler complains when it reaches the first reference to yylval in the new bison.tab.cc, saying that 'yylval' was not declared in this scope. This corresponds to my first use of 'yylval' in my .y file. I'm using the C++ skeleton (lalr1.cc), and not explicitly declaring a pure-parser. http://stackoverflow.com/questions/23685843/problems-with-yylval-and-yylloc-after-switching-to-bison-3-0 is the same question on stackoverflow, from May 15th, with a suggestion to use yyla.value instead. Thanks. ___ help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison
Re: newbie: better approach for list processing with bison++?
This is perhaps more canonical:
param_list
: /* nothing */ { $$ = new ParamListNode(); }
| param_item_list{ $$ = $1; }
;
param_item_list
: param { $$ = new ParamListNode($1); }
| param_item_list ',' param { $$ = $1-addChild($3); }
;
so bare with me!
Think I'll pass on that.
___
help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison
Re: Solving issue in templates
On 05/02/2013 23:54, Adam Smalin wrote: This doesn't help :( I see is in the lexer (search SHL) which means ListListint will not compile because is a right shift. But i looked in the y file first and well... like i said its a C++ problem so C++ obviously would suffer from it. Why have you got an issue with solving this in the AST logic? You can't expect to compile any reasonably complex language in a lexer and a parser. The lexer sorts out tokens, the parser lets you produce an first attempt at an AST. All the hard work happens afterwards. You're going to have to fix up hundreds of other things by manipulating the AST, so you might as well just get on with it. ___ help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison
Re: filebench: bison generated parser + CDDL
You'll never get an answer from the FSF on licensing; they'll just send you a form mail asking you for money. So, don't bother asking. You have to ask yourself two questions: 1 - Is filebench a parser generator? From what you've said, it seems that it isn't. If it isn't a parser generator (ie. if it just *contains* a parser, and it isn't a program (like yacc/Bison/Antlr/etc) which actually *creates* a parser) then you can distribute filebench under any licence you want, even though you have used Bison to generate a parser which you have included in filebench, and even though filebench uses the Bison skeleton. This much is obvious; Bison would be unusable in most environments without this exception. 2 - Do you actually *want* to distribute filebench with a *more* restrictive licence that contaminates the rest of your code, and restricts your ability to distribute your code freely? If so, you can. This is what the Alternatively section is about. You can completely ignore the Alternatively section, unless you have some sort of ideology issue with licences. I think your confusion is: It is less clear than I thought. Let A be a work with a parser generated by bison and assume that A is not a parser generator. It appears that the exception allows the authors of A to place A under any license they want to, effectively overriding the GPL-and-exception. Suppose they choose something like the MIT license. Then No - you can't over-ride the GPL-and-exception. You can only over-ride the -and-exception: | Alternatively, if you modify or redistribute | the parser skeleton itself, you may (at your option) remove this | special exception, which will cause the skeleton and the resulting | Bison output files to be licensed under the GNU General Public | License without this special exception. In other words, you can make the licensing *more* restrictive, by reverting back to GPL, but you can't make it *less* restrictive. I'm sure you're Ok. But, if you're really concerned, you can always switch to Antlr, which has a free licence, rather than a Free licence. -Evan ___ help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison
Re: Rule not matched ?
What is 'design_file'? Does it expect a START_FULL before LIBRARY? Is 'switch' invoked anywhere else? Do you have any 'go to state 0' output in your debug file? Does START_FULL appear anywhere else in your grammar? Which 'modification' are you removing? Both, or just the start rule? -Evan ___ help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison
Re: Selective Compilation
On 07/02/2011 23:13, Tejas Kajarekar wrote: Hi Martin, If I understand your question correctly, here is a way to have multiple scanners and parsers in the same program. No, he's asking about using a subset of an existing grammar in a new parser. Example: I have a language which includes a complex expression syntax. I also have a separate preprocessor for the same language, which uses exactly the same expression syntax. This means that I need to write two completely separate flex/bison files, and maintain both of them, even though one of them is a subset of the other one. This would be a nice feature - I think it's been asked for before on this list. ___ help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: parenthesis warnings
On 17 Dec 2010, at 17:08, Gergely Feldhoffer wrote: Thank you, we upgraded bison from latest debian 2.4.1 to 2.4.3, and it works just fine. I just had this problem on the default Ubuntu 10.10 installation (gcc 4.4.5, bison 2.4.1). Anyone who wants to stay on 2.4.1 needs to edit the location.cc skeleton file to add the extra parentheses. In my case, this file is in /usr/share/bison. The source for the code at position.hh:136 is at line 120 in location.cc; just add parentheses around the 2 expressions on either side of the '||'. I was surprised to see this in my grammars, though, since I don't use %locations. Should the position/location code be generated if it's not required? -Evan ___ help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: bison 2.4.1 on Msys Win7 /usr/local/share/bison/m4sugar/m4sugar.m4
Sanity check: presumably you know that you don't have to build on MSYS to get a Win32 executable? You can build on Cygwin, with MinGW. You can ignore MSYS completely, and the result doesn't use cygwin.dll. -Evan ___ help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: help-bison Digest, Vol 79, Issue 4
Dick Dunbar wrote: I didn't know that. And don't know how to proceed. I have gcc installed on cygwin; does it need to be replaced with a MinGW distro? Any pointers to a discussion of this? No; just install the MinGW gcc. You can get this from the Cygwin installer, but I think I downloaded mine direct. There's an installation HOWTO on the MinGW website. The trick is to put the MinGW path before the Cygwin path, so you pick up the MinGW gcc. This is all a bit of a black art, but there's lots on Google about it. The only issue, I think, is making sure you get the path right. One potential problem is that the MinGW gcc is (was?) not up-to-date. I don't have a Windows system up, but I think I have to run gcc 3.4. HTH -Evan ___ help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: Newbie: how to get rid of this r/r conflict
You haven't given enough information; it looks like there's an embedded action you've left out. Construct a simple test case and post it. Alternatively, just start with the production as shown in SV3.1a: timeunits_declaration : timeunit time_literal ';' | timeprecision time_literal ';' | timeunit time_literal ';' timeprecision time_literal ';' | timeprecision time_literal ';' timeunit time_literal ';' ; there are no conflicts in this. -Evan ___ help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: Two-pass parser or AST with Bison?
I had this problem some years ago, when I was first using Bison. I had a
simple language, which I could handle in a single parser pass; this was
easy, and I could do everything in the Bison actions.
I then added some functionality, which was primarily forward-referencing
of externals (mainly function calls, like you). I fixed this quickly by
adding a second Bison pass; the parser re-scanned the original source
code (I didn't bother saving and re-scanning flex tokens, as you're
suggesting).
(2) (for two-pass:)
Don't want to surround every single rule with an if like this:
E = E '+' E {
if(global.pass==1) {
// do nothing in first pass
} else {
code_append(OP_ADD);
}
}
I had a lot of this, but I mainly put it in the C++ code called from the
actions, where it was a trivial addition - if you're in the wrong pass,
you just return. This keeps the grammar clean. Alternatively, you might
also consider writing two grammars - in the first pass, you use a
simplified grammar which ignores the contents of functions, and which
just extracts function names and parameters.
If you're just forward-referencing function names, then two Bison parses
is *much*, *much* easier than creating and processing an AST. In my
case, the language got more complicated over time, and I needed a third
pass. It was only then that I started using an AST - the parser pass
created the AST, and subsequent passes manipulated the AST (there were
eventually 6 passes).
Using an AST for the first time is hard work and there's a steep
learning curve (I used the C++ AST library from ANTLR to make this
easier). You should also remember that writing an AST-based compiler is
a completely different programming paradigm from a simple parsing
exercise. The former is all about data and manipulating data structures;
the latter is just actions and functions.
(1) (for the AST:)
Don't want to spell out every single AST node class explicitly, but
rather, if possible, derive these from the grammar?
I don't think that would be desirable (even if it's possible). As a
programmer, you'll be constantly modifying, adding, or removing node
classes to make life easier. For example, some passes might want a new
node class because they've simplified part of the tree and want to
replace it with an equivalent node, where that node has no equivalent in
the source code. Eventually, your AST will transform to something which
looks nothing like your source code, so why should it uses node types
which are defined by the source?
Good luck -
Evan
___
help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: Two-pass parser or AST with Bison?
Matthias Kramm wrote:
I'll probably define myself some C macros so that I can at least
write something like
E = E '+' E {pass2only append($1);append($3);append(OP_ADD);}
.
But it would of course be more nifty if the default behaviour
execute an action only if the pass is 2 could be placed
somewhere central.
You really want a bison equivalent of flex's YY_USER_ACTION, but I don't
think there is one. You could hack the bison output if you're desperate
- maybe something in/around YY_REDUCE_PRINT.
Any pointers to a pure C AST implementation, by any chance?
There's a C runtime for Antlr, so I guess all the AST code has C
versions as well - I don't think it existed when I needed it. The C++
version has ~80 .hpp and .cpp files for the AST bits (I think I found it
in a lib directory somewhere in the source tree).
-Evan
___
help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: SQL grammar
Check the logs, as Hans suggests. For starters, though, what's this: NOT IN ((SELECT '*' FROM SCONST)) What sort of 'search_cond' is it? First branch, second branch, or both? It can't be both; that's a conflict. Evan ___ help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: SQL grammar
Evan Lavelle wrote: Check the logs, as Hans suggests. For starters, though, what's this: NOT IN ((SELECT '*' FROM SCONST)) What sort of 'search_cond' is it? First branch, second branch, or both? It can't be both; that's a conflict. Sorry, didn't read your first post; seems you already knew this. There's no general fix. You need a detailed understanding of your language, and you have to formulate the grammar in a way that doesn't have these overlaps. There are a lot of SQL parsers on the net, so that would be a good place to start. In this simple case, your problem is that a query_specification can be both a query and an expression. This might make sense to a human, but not to a parser. You appear to be trying to fix this by the use of brackets, but this won't work, since a bracketed expression is still an expression. There are various things you can try, but which one you should use depends on the language itself, which I know nothing about: 1 - completely subsume queries into expressions 2 - completely exclude queries from expressions 3 - allow both query_lists and expressions to include query_specifications, but make sure that you never write a production that actually uses both a query_list and an expression Evan ___ help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: for loops in C style
Ilyes Gouta wrote:
Basically what it's done is enumerating all the possibilities for the
construction of the for loop. Is it the only way do things clearly and
properly?
There's no 'clear and proper' way to do this; do whatever's best for
you, try it, fix it, repeat. Here's what I do:
iteration_statement
...
| FOR '(' loop_init ';' loop_cond_opt ';' loop_term ')' loop_body {
...
}
;
loop_init
: /* nothing */ { ... }
| full_expr { ... }
;
loop_cond_opt
: /* nothing */ { ... }
| full_expr { ... }
;
loop_term
: /* nothing */ { ... }
| full_expr { ... }
;
loop_body : ... ;
You can trivially change or fix the grammar; the real problem is the
actions, and how you construct the AST. You'll also find that C grammars
aren't much use to you, because assignments aren't expressions in your
language.
Evan
___
help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: can't to remove shift/reduce
If you want help with a grammar, you need to do one of two things:
- post a grammar that fails. Put '%%' around it, make sure that there
are no undefined rules, cut out all actions, and run Bison on it. Don't
post everything: if 'expr' isn't relevant, add expr : 'A' ;, for
example, or
- Show some rules, and give some input that fails those rules.
You haven't done either of these.
Pavel Stehule wrote:
Hello
I have gram file that works.
I'd be surprised if it works. Have you tried column_method_name both
with and without brackets? The default is to ignore the brackets - what
happens then? How are the brackets interpreted?
You need to post everything that can come after 'column_method'. Is it
ever possible to have a '(' character after a column_method, apart from
the 2 ways you have shown?
Evan
___
help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: can't to remove shift/reduce
It's too big to make much sense of, but here's a couple of things you
can try:
I'd be surprised if it works. Have you tried column_method_name both
with and without brackets? The default is to ignore the brackets - what
happens then? How are the brackets interpreted?
without brackets it is relation or variable atribute. With brackets it
is methods.
The grammar produces no code for the no-brackets case (relation or
variable attribute). It doesn't reduce; it assumes that you wanted the
shift, so it assumes with brackets it is methods. Is this acceptable,
or not? Have you got any test input that explicitly requires the
no-brackets relation or variable attribute case?
You need to post everything that can come after 'column_method'. Is it
ever possible to have a '(' character after a column_method, apart from
the 2 ways you have shown?
To rephrase this: if your intention is to allow both of these two things:
1 - column_method, with no following '(' (ie. relation or variable
attribute), *but* some other part of the grammar allows you to put in a
following '(' anyway, AND
2 - column_method with a following '(' (ie. with brackets it is
methods), THEN
you have a language ambiguity that you need to fix. At first sight, it
seems that perhaps you may want case 1, because (at least) both
func_name and qualified_name can be followed by '('. If you don't know
the answer, you need to go right through the grammar to find out if case
1 is a requirement.
Evan
___
help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: Top Dowm Variable Communication
Arijit Das wrote:
Even though Bison is a bottom up parser, if I need to pass a variable's
content top-down, what are the possible ways (except using global
variable)?
Register_decl
: REGISTER IDENTIFIER Register_decl_contd
{
Char * register_name = $2;
// $2 has the 'register_name' now. I wanted that
name to be communicated down to the scope of the non-terminal
'Register_decl_contd'
}
;
Register_decl_contd
: '.' IDENTIFIER ...something...
{ ... }
| '=' IDENTIFIER ...something...
{ ... }
| '[' IDENTIFIER ...something...
{
// I want to use get the content of
'register_name' here to be able to print user friendly error messages,
if required.
// How can I get that info since register_name
is defined in a top level scope in the non-terminal hierarchy? Any help?
}
;
Thanks
Arijit
Some quick thoughts, which may or may not be helpful:
- what's wrong with global variables?
- context-dependent information is generally handled better at a higher
level than scanning. If you just use the scanner to build an AST, for
example, then all the information you need is encoded into the AST, and
the context is then obvious.
- look up inherited attributes (or synthesised attributes), which
should fix your immediate problem. Basically, $0, $-1, etc let you
access symbols on the stack to the left of the current rule. However,
you should only really do this as a last resort.
- If you need to do a lot of this, and don't want to build an AST, it
may be helpful to look at using Antlr instead of bison.
Evan
___
help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: shift/reduce conflict with unary
Actually, it turns out that the conflict is pretty obvious even without the debug output. consider this input: 5 6 +4 How do you expect this to be scanned? Does it contain 3 summation_expressions (5, 6, +4) or 2 (5, 6+4)? There's an ambiguity - you haven't defined an expression list in an unambiguuous way. this is a very common problem - how do you define a list of something complex? Can you define expression lists to require a separator? How about 5, 6, +4 - 3 expressions 5, 6 +4 - 2 expressions Is it okay if I disregard the conflict if the grammar works anyway? I personally think that this is a mistake, but it is commonly done. The problems are that you may not understand why there is a conflict in the first place, and any subsequent maintainers certainly won't understand; I prefer to try to remove the conflict. Evan ___ help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: shift/reduce conflict with unary
cwcaceres wrote: But I'm not trying to list. I'm trying to do the add operation. So the expression 5 6 +4 wouldn't be valid. An example of a valid operation would be +5 + -6 - -2 which should have an output of 1. My grammar file currently outputs the correct result. I agree with trying to remove the conflict but I'm putting that on hold for now since I can't think of how to remove it. I'm writing this with the benefit of 10 minutes exposure to your problem, so I may well be wrong. However, I think you need to stop and think a bit more. The expression 5 6 +4 *is* valid according to the grammar; try it. It may not be valid according to your intent, which is a rather different matter. Read the debug output, and walk through a scan of 5 6 +4. After scanning '6', the parser has to decide whether the '+' marks the start of a new unary expression, or is an addition operator. If it's the former, then it has to reduce a summation expression; if the latter, it has to shift for the addition. That's your conflict. The default is to reduce, ie. to push onto the expression list, which I don't think is what you want. You say that you're not trying to list. But that's exactly what expression_list : /* empty */ | expression_list summation_expression ; does; it parses a list of summation expressions. What is the intent of expression_list? Evan ___ help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: Conflicts in large grammar
Hans Aberg wrote: http://savannah.gnu.org/svn/?group=bison Error: this project has turned off this tool ?! I sympathise. If I ever get enough time, I'll probably be converting back from svn to cvs. Evan ___ help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: Conflicts in large grammar
Hans Aberg wrote: On 9 Aug 2007, at 10:55, Evan Lavelle wrote: http://savannah.gnu.org/svn/?group=bison Error: this project has turned off this tool ?! I sympathise. If I ever get enough time, I'll probably be converting back from svn to cvs. What are the cons and pros of the two? Mac OS X 10.4.10 comes with CVS but not the other, so that one is easier for me. Whoa; I hate this discussion. There's a long list of pros and cons, but as an actual user, who has to do a real job in which svn or cvs takes up only 5 minutes in the day, there are (I think...) only 2 significant issues. The good part of svn is that you can easily manipulate directories and files (moving and renaming). This is great, and it's hard work in cvs, but you don't need to do it often. What I personally need revision control for is to restore a file when I mess it up. For this, you generally need to go back one revision on the file, and compare the old and new versions. If you're using emacs, this is trivial; you can easily ediff the two versions in side-by-side windows. It's more difficult for svn - you have to find the last version of the file which was actually different (and it may have been hundreds of versions ago), restore it, and then manually run up ediff. Ok, it's not too difficult, but it's bad enough. The svn modes for emacs are next to useless (unless they've improved over the last year). Ok, this is a problem with emacs rather than svn, but that makes no difference to me as a user. In short, the effort of installing svn was, for me, just pointless busywork. Evan ___ help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: Feature request
Fernando Ferreira wrote: The reason for my request is that, as bison generates LR parsers, there is no way to, for instance, execute an action before a rule is reduced, only after. I've never tried an action at the start of a rule, but I'm pretty sure that you can do it. Look up 'embedded actions' in the O'Reilly lexyacc book, or 3.5.5 'Actions in mid-rule' in the Bison 2.0 manual. It may be difficult to avoid conflicts, though. According to the O'Reilly book, yacc implements embedded actions using the technique described at the end of 3.5.5 (Another solution is to bury the action inside a nonterminal symbol which serves as a subroutine...). Evan ___ help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: Grammar failing single lookahead
Evan Lavelle wrote: Prolog : FirstPrologList | SecondPrologList | FirstPrologList SecondPrologList ; I missed the case of no prolog at all, but this has no conflicts: Prolog : /* nothing */ | FirstPrologList | SecondPrologList | FirstPrologList SecondPrologList ; Evan ___ help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Token push-back?
I'm just about to write a yylex wrapper to let me push back a token so
that Bison can re-read it. Before I do this, can anyone tell me if
there's a better way to handle this?
My problem is that I need to write a partial parser, which ignores large
chunks of a language. The chunks are delimited by known tokens, so I
need to do something like
ignore_block
: STARTBLOCK {
// check yylex input for ENDBLOCK, push it back
} ENDBLOCK ;
ie. something like a flex exclusive start state, but initiated from Bison.
Thanks -
Evan
___
help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: bison and C++
Hans Aberg wrote: Once upon the time, Bison had an informal support for the C-parser to be compiled as C++, but this was dropped, being too difficult to maintain. Instead, a separate C++ skeleton was developed. So, for C++, it is best to use the C++ skeleton file. I have a lot of C++ code in my .y file, and no problems. This is 1.875c - has this support been dropped since then? But then, I can't immediately see why any C++ support is required, as long as you use the union/struct mechanism for passing data. My YYSTYPE is a struct which contains reference-counted classes. Maybe this is the confusion? Do you only need the C++ skeleton if your YYSTYPE is a real C++ class? BTW, you don't even need Satya's 'extern C' declarations if you're using gcc; don't know about other compilers. Evan ___ help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: Bison flex on start conditions
Henrik Sorensen wrote: On Friday 13 January 2006 13.10, Steve Murphy wrote: One that would be nice to smooth out would be the start-condition capability in flex... and how to trigger it from the bison grammar end of things. Can you be more specific why you want to do this ? It gives you much more powerful context-sensitive parsing; it can remove the need for multi-token lookahead in many cases. One obvious application is detecting tokens which might be keywords, or might not be, depending on context. It would certainly have saved me a lot of trouble. Evan ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: Cookie replacement function
A couple of things to watch out for:
[[:alnum:]]+yylval = yytext; return WORD;
^.*$yylval = yytext; return STRING;
what are you trying to match here? Is your reasoning that any
alphanumeric will get caught in the 1st rule, and everything else in the
2nd? This won't work - any alphanumeric will actually be caught by the
2nd rule, because of the explicit '$'/NL match. Try to handle your NLs
explicitly, and/or use more explicit/descriptive regexps.
cookie: STRING
|
'%' '{' WORD '}'
You need a catch-all rule to let through %, {, and }, otherwise this
will be matched as a STRING; something like
. return yytext[0];
HTH -
Evan
___
Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: Problems with epsilon productions
Arlen Cox wrote: I am trying to implement a grammar that may have 0 or more of a construct. Effectively I want to have a grammar like this: File: ( Module )* File : /* nothing */ | File Module ; Google 'left recursion', or converting between LALR and LL grammars (or LR and LL). There are a number of articles on the Antlr site that cover this. Also see if you can get a copy of 'lex yacc' (1-56592-000-7). Evan ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: %union and shared pointers to AST nodes
struct yystype {
...
antlr::RefToken tok;
antlr::RefASTast;
};
#define YYSTYPE yystype
Evan
___
Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: Lexical feedback and lookahead
Hans Aberg wrote:
On 19 Jul 2005, at 17:01, Evan Lavelle wrote:
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.
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.
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. 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.
Evan
___
Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
