Le mercredi 20 juillet 2005 à 01:42 +0200, Hans Aberg a écrit :
thanks you very much for the quick answer!
> > 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 s
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 too
if you receive for twice time this message i'm sorry i made a mistake
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 bui
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?)
how recover number (they could cha
Should yychar be reliable in semantic actions when declaring %glr-parser?
It gives results that I do not expect for both bison 1.875 and 2.0. I can
understand that delayed semantic actions might cause trouble in the case
of ambiguous grammars (although it would be nice if they didn't).
However, fo
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
On 19 Jul 2005, at 15:00, Evan Lavelle wrote:
Thanks for the input on this. I can't really use the pointer
solutions, so my current fix is to define YYSTYPE as a struct,
rather than a union, and to pass around classes in the struct. This
seems to work well, though it's inefficient.
I use
Thanks Tim. At first sight, this fix should be exactly what I need;
however, in my case, it doesn't work... :(
The problem is that COBOL has a real keyword - FUNCTION - to 'lock on'
to. So, in your production:
xxx
: { recognize_function_names = true; } FUNCTION valid_function
;
the lexer c
I am attempting to use bison's %glr-parser and %merge to construct parse
forests. I'm getting duplicate representations of some trees within the
forest. Both bison 1.875 and 2.0 give the same results.
The problem is that, for some grammars, the parser invokes some semantic
actions and my merge f
Evan Lavelle wrote:
> I've got a problem where I need some communication back from Bison to
> Flex (in this case, I need Flex to return two different tokens for the
> same input, depending on context).
>
> The procedure is something like:
>
> 1 - parser determines context and sets global flag for
I've got a problem where I need some communication back from Bison to
Flex (in this case, I need Flex to return two different tokens for the
same input, depending on context).
The procedure is something like:
1 - parser determines context and sets global flag for lexer
2 - lexer checks flag,
Thanks for the input on this. I can't really use the pointer solutions,
so my current fix is to define YYSTYPE as a struct, rather than a union,
and to pass around classes in the struct. This seems to work well,
though it's inefficient.
The reason that reference counting is required here is th
12 matches
Mail list logo
