Re: Return from recursive processing is incomplete

[Philip Herron]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Evan Carew wrote:
> I'm working with Bison 2.0 on linux and am having trouble getting
> all of the output from a recursive call to a rule. I have input a
> piece of C code which represents an enum into a lexer designed for
> C and a bison rule set designed for C as well. I was hoping to use
> the generated parser to do some automated ode rewrites, but an
> having trouble figuring out how to access the output.
>
> If I take the default action {$$ = $1} for all rules, I get my
> input echoed back out. If I try to edit the default actions, I get
> strange behavior. Specifically, when I am trying to programitally
> access the enumerator list elements in the enum rules, no matter
> how many enumerators I have between the braces, I only get the
> first one back. For the following code, where it says "Look Here!",
> I've tried everything to get out all the enumerations. My input was
> [enum blah { one, two, three }; ] what I get back is [enum blah
> {one };]. Has anyone run into this before? BTW, I happen to have
> John Levine's Flex and Bison by my elbow as I type this.
>
> enum_specifier : ENUM '{' enumerator_list '}' { /*emit("enum { %s
> }", $3); */} | ENUM IDENTIFIER '{' enumerator_list '}' {/* Look
> Here!*/} | ENUM IDENTIFIER { /*emit("enum %s", $2); */} ;
>
> enumerator_list : enumerator | enumerator_list ',' enumerator ;
>
> enumerator : IDENTIFIER | IDENTIFIER '=' constant_expression ;
>
>


Took me a few times to read your mail to see what you meant :P. So let
me know if i am wrong i but, you want to understand a way of
representing syntax like:

enum foo { bla, bla, bla, bla };

So take a look at your toplevel for an enum:

enum_specifier: ENUM '{' enumerator_list '}'

enumerator_list
    : enumerator
    | enumerator_list ',' enumerator
    ;

enumerator
    : IDENTIFIER
    | IDENTIFIER '=' constant_expression
    ;

This looks fine its a standard way of expressing lists, but you have
to think about how should each rule represent what you want? You said
" what I get back is [enum blah {one };]"

What i would do for now is to be very basic for keep a sanity check :)
So only return char* for enumerator:

%type<string> enumerator

So an enumerator rule would be simply:

enumerator : IDENTIFIER
{
    $$= $1;
}

Then it gets a little more fiddly you have to think how do you handle
a list and could be n length? In a language i have a list does this:

list_type: '{' item_list '}'
         {
       $$= tmp_table;
       tmp_table= NULL;
         }
         ;

item_list: item_list ',' item
         {
       if( tmp_table )
         append_element( $3, &tmp_table );
      else
        fatal("NULL list table in list construction!\n");
         }
         | item
     {
       if( tmp_table )
         append_element( $1, &tmp_table );
       else
         {
           tmp_table= (struct hash_table*)
         xmalloc(sizeof(struct hash_table));

           init_hash_table( tmp_table );
           append_element( $1, &tmp_table );
         }
     }
         ;

What i have is a tmp_table which is a hash table and i just keep
appending to that structure and my list is a hash_table but this
affects what is an item.

item: IDENTIFIER
    {
      struct symtab *sym= (struct symtab*)
    xmalloc(sizeof(struct symtab));
 
....
      $$= sym;
    }
    | INTEGER
    {
      struct symtab *sym= (struct symtab*)
    xmalloc(sizeof(struct symtab));

     ...
    }
    | DOUBLE
    {
 ....
    }

//.....

Thats quick extract, everything is a symbol in my language a little
like python everything is a python object and so i just append symbols
to a table. This is a very linear way but its ok because i dont accept
lists defined inside lists but you can have another variable that is a
list and just add that item into a new list so its a list of lists.

This is one way of doing it you could keep a stack or something and
return that or list. You could have an array of buffers or something
it depends how you want it to work.

You just have to think if i had this is 'a' structure what would it do
and why and how would it work then maybe you might find what you need
to do. Remember bison will simply parses the tokens but you have to
act on the rules in a way thats useful for you.

- --Phil
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkqjxwIACgkQAhcOgIaQQ2HmLwCeMbo1QWMf+UavSRzGPulRMfyN
H3UAn0UxZI1dv+psctFykiMbb5kZq2me
=Rleh
-----END PGP SIGNATURE-----