GUI Parser Project: Recursive Descent Parser for GUI Definition

This project focuses on the development of a GUI parser using a recursive descent technique. The assignment requires the implementation of a lexer to recognize terminal symbols, followed by the creation of a recursive descent parser to parse an input file defining a GUI. The parser must be capable of detecting syntax errors and generating an output file that details the parsing steps. The GUI definition language includes elements such as windows, layouts, and various widgets like buttons, text fields, and radio buttons. The project emphasizes the application of compiler design principles, including lexical and syntax analysis, to process and interpret the structure of the GUI definition language. The solution involves parsing the input file and outputting the parsing steps in a manner similar to that described in compiler design textbooks, demonstrating a deep understanding of parsing techniques and error handling within the context of programming language processing.

Instructions
The first programming project involves writing a program that parses, using
recursive descent, a GUI definition language defined in an input file and
generates the GUI that it defines. The grammar for this language is defined
below:
gui ::= Window STRING '(' NUMBER ',' NUMBER ')' layout widgets End '.'
layout ::= Layout layout_type ':'
layout_type ::=
Flow '(' [ align ] ')'|
Border '(' [ NUMBER ',' NUMBER ] ')'|
Grid '(' NUMBER ',' NUMBER [',' NUMBER ',' NUMBER] ')'
align ::= LEFT | RIGHT | CENTER
widgets ::= widget widgets | widget
widget ::=
Button STRING ';' |
Group radio_buttons End ';' |
Label STRING ';' |
Panel layout widgets End ';' |
Textfield NUMBER ';'
radio_buttons ::= radio_button radio_buttons | radio_button
radio_button ::= Radio STRING ';'
In the above grammar, the red symbols are nonterminals, the blue symbols
are tokens and the black punctuation symbols are BNF metasymbols.
Among the tokens those in title case are keywords. The character literals
are punctuation tokens.
Below is an explanation of the meaning of some of the symbols in the above
productions that should help you understand the actions that are to be
performed when each of the productions is parsed:
 In the window production the string is name that is to appear in the top
border of the window and the two numbers are the width and height of the
window
 In the production for layout_type that define the grid layout, the first two
numbers represent the number of rows and columns, and the optional next
two the horizontal and vertical gaps

 In the production for widget that defines a button, the string is the name of
the button
 In the production for widget that defines a label, the string is text that is to
be placed in the label
 In the production for widget that defines a text field, the number is the width
of the text field
 In the production for radio_button, the string is the label of the button
You parser should properly handle the fact that panels can be nested in
other panels. Recursive productions must be implemented using recursion.
Lexical and syntactical errors should be detected and reported (the first
error only; after reporting the first error the program must exit gracefully).
Below is an example of an input file:
Window "Calculator" (200, 200) Layout Flow():
Textfield 20;
Panel Layout Grid(4, 3, 5, 5):
Button "7";
Button "8";
Button "9";
Button "4";
Button "5";
Button "6";
Button "1";
Button "2";
Button "3";
Label "";
Button "0";
End;
End.
Just to give you an idea where that input file came from, the above input file corresponds to the
GUI shown below:

However, please keep in mind that you are NOT required to re-create the
GUI that corresponds to the input file. Instead, you are only required to:
1. Implement a lexer capable of recognizing all the terminal symbols of the
grammar (tokens/lexemes - those in blue)
2. Implement a recursive descent parser that (using the lexer from 1.) will
be able to parse the input file and detect a syntax error (the first one is
enough, then the parser should exit gracefully)
3. As a result of parsing the input file, an output file will be generated,
reporting the parsing steps followed by the parser in a manner similar to
the one described by Sebesta (10th edition) on pages 181-186.
Notes:
- You can implement the parser for this grammar in C, C++, Java or C#
- Additional input files will be provided for testing
- The complete list of deliverables will be specified very soon in a separate
post
Attachments