Re: Standalone problem to test syntax rules

[Marco Gerards]

Bean <address@hidden> writes:


Hi Bean,

> I have written a small problem to test my parse.y, to compile, use the
> following commands:
>
> bison -d -p grub_script_yy -b grub_script parser.y 
> gcc -oparser parser.c lexer.c grub_script.tab.c
>
> After compilation, run parser
>
> ./parser
>
> Just enter the commands after '##', and the syntax tree associtaed with it
> will be displayed.
>
> The program support option - , which is used to disable prompt '##' and '>>'.
> This is useful when inputting from files:
>
> ./parser - < input_file
>
> Some example:
>
> ## aa "aa${BB}cc" "\
>>dd"
> CMD
>   TEXT
>     STR  "aa"
>   TEXT
>     STR  "aa"
>     VAR  "BB"
>     STR  "cc"
>   TEXT
>     STR  "dd"

[...]

> The reason why I like to use binary tree is:
>
> 1. Standard data type for all script elements, only one set of function is
> needed to manipulate the structure.
>
> 2. Enumeration and deallocation is simpler. Instead of using switch, we
> can enumerate the tree using its two branch, child and next.
>
> I also figure out how to release memory when syntax error occurs. When a
> node is first created using grub_script_newnode, it's added to a linked
> list state->free_list. When it's referenced, it's moved from the linked
> list to the branch of a tree. If the whole script is parsed, all nodes
> will be moved to the final tree, but if it fails at some point, partial
> built element can be found in the free list. This way, we can also keep
> track of nodes allocated. For example, consider this command:

You are right that it has advantages.  But I prefer using an Abstract
Syntax Tree.  It is used a lot in most literature on parsers, clean
and easy to understand.

The disadvantage is that you need a separate free routine for each
kind of node.  But heck, we can even generalize this!

I agree there is a lot of room for improvement.  But stepping away
from using ASTs is not the way to go in my opinion.

--
Marco