Re: Grammar definition problem.
Hey Laurence, Thanks! that was nice and simple, I should have go that :( earlier! Regards, Atul. On Mon, 21 Mar 2005 11:59:49 +0100 (MET), Laurence Finston <[EMAIL PROTECTED]> wrote: > On Mon, 21 Mar 2005, Atul Kulkarni wrote: > > > 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? > > x: letter extension > > extension: /* Empty */ > > extension: extension letter > > extension: extension digit > > Laurence Finston > ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: %union errors that shouldn't be there
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. Thanks. Laurence ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: %union errors that shouldn't be there
On Sun, 20 Mar 2005, DYP wrote:
> My %union is declared in the following way [...]
>
> %union{
> float fconst;
> int type;
> astNode* node;
> string* name;
> nodeList* list;
>}
>
If you don't mind an unsolicited suggestion, you might want
to consider using a `void*' instead of three different
pointer types in your `%union' declaration. This would make
it possible to simplify your `%token' and `%type'
declarations, and you'd be able to use a pointer to any type
as the semantic value of a given token without changing the
`%union' declaration.
For example, this is my `%union' declaration:
@=%union@>
{
char string_value[64];
double real_value;
signed int int_value;
void* pointer_value;
};
These are two `%type' declarations for non-terminal symbols:
@=%type point_primary@>@/
@=%type path_primary@>@/
The semantic value of a `point_primary' symbol is a pointer
to an object of type `class Point', cast to `void*', whereas
that of a `path_primary' symbol is a pointer to an object of
type `class Path', cast to `void*'. The pointers must be
cast to the proper type in the rules, but this is always
clear. For example, in the rule
`path_primary: SUBPATH numeric_list OF path_primary',
`$4' can only be a `Path*', cast to `void*'.
In my next parser, I will probably simply use `void*' as
`YYSTYPE' and not bother with `%union'. In this one, it is
convenient to let the parser code generated by Bison take
care of allocating and freeing memory for the other members
of the `union', but this must be weighed against the
simplicity of being able to treat all objects representing
semantic values in the same way. There are also issues
involving the `%destructor' feature and error recovery.
Laurence
___
Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: %union errors that shouldn't be there
On Tue, 22 Mar 2005, Laurence Finston wrote: > @=%type path_primary@>@/ > [...] in the rule > `path_primary: SUBPATH numeric_list OF path_primary', > `$4' can only be a `Path*', cast to `void*'. This isn't true. The semantic value of a symbol of type `pointer_value' can be 0, which I've found to be very useful. Laurence ___ 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
Update Your Account
Hello Dear PayPal Member! For our Security Problems You Should Update Your PayPal Account Please Click Here To Update Your Account Thanks You For Using PayPal! The PayPal Team PayPal Email ID PP456 ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
