The goal of this project is to give you experience in writing a top-down recursive descent parser and to get introduced to the basics of symbol tables for nested scopes. -- 2

We begin by introducing the grammar of our language. Then we will discuss the semantics of our language that involves lexical scoping rules and name resolution. Finally we will go over a few examples and formalize the expected output.

NOTE: This project is significantly more involved than the first project. You should start on it immediately. For Monday, I expect that you have read the project description completely at least a couple times and maybe started on your parser.

1. Lexical Specification

And here is the list of tokens that your lexical analyzer needs to support:

Comments and Space

In addition to these tokens, our input programs might have comments that should be ignored by the lexical analyzer. A comment starts with // and continues until a newline character is encountered. The regular expressions for comments is: // (any)* \n in which any is defined to be any character except \n . Also, like in the first project, your lexical analyzer should skip space between tokens.

2. Grammar

Here is the grammar for our input language:

program global_vars global_vars var_list var_list scope public_vars public_vars private_vars private_vars stmt_list stmt_list stmt

stmt

-> global_vars scope

-> ε

-> var_list SEMICOLON

-> ID

-> ID COMMA var_list

-> ID LBRACE public_vars private_vars stmt_list RBRACE

-> ε

-> PUBLIC COLON var_list SEMICOLON

-> ε

-> PRIVATE COLON var_list SEMICOLON

-> stmt

-> stmt stmt_list

-> ID EQUAL ID SEMICOLON

-> scope

Here is an example input program with comments:

Note that our grammar does not recognize comments, so our parser would not know anything about comments, but our lexical analyzer would deal with comments. This is similar to handling of spaces by the lexer, the lexer skips the spaces. In a similar fashion, your lexer should skip

comments.

We highlight some of the syntactical elements of the language: Global variables are optional

The scopes have optional public and private variables Every scope has a body which is a list of statements

A statement can be either a simple assignment or another scope (a nested scope)

3. Scoping and Resolving References

Here are the scoping rules for our language:

The public variables of a scope are accessible to its nested scopes

The private variables of a scope are not accessible to its nested scopes Lexical scoping rules are used to resolve name references

Global variables are accessible to all scopes

Every reference to a variable is resolved to a specific declaration by specifying the variable's defining scope. We will use the following notation to specify declarations:

If variable

is declared in the global variables list, we use

to refer to it

If variable

is declared in scope

we use b.a to refer to it

And if reference to name a cannot be resolved, we denote that by ?.a

Here is the example program from the previous section, with all name references resolved (look at the comments):

a

x =

= b;

hello; //

// test.a

?.x = = nested.b

[login to view URL]

c = y; // ::c = ?.y

}

}

4. Examples

The simplest possible program would be:

IT IS CONTINUATION OF the PREVIOUS PROJECT. PLEASE LOOK AT THE ATTACHED FILES FOR DETAILED INFO. WILLING TO PAY MORE THAN 30$$$$$ BUT IT DEPENDS ON YOUR PROFILE.

Programación en C Programación en C++ Ubuntu

Nº del proyecto: #26622873

Sobre el proyecto