Bean <[EMAIL PROTECTED]> 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
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
