CMSC 430 Project 2

Could someone help me fix the code below in cgywin64 to correct the errors in bold at the bottom Below is the description of the question, followed by the codes, and the errors in bold. Thank you so much for the help. Please modify the given code instead of making a new one.

Description:

The question involves modifying the syntactic analyzer for the attached compiler by adding to the existing grammar. The full grammar of the language is shown below. The highlighted portions of the grammar show what you must either modify or add to the existing grammar.

function:

function_header {variable} body

function_header:

FUNCTION

IDENTIFIER

[parameters] RETURNS type ;

variable:

IDENTIFIER : type

IS statement

parameters: parameter {, parameter}

parameter:

IDENTIFIER : type

type: INTEGER | REAL | BOOLEAN

body: BEGIN statement END ;

statement:

expression ; |

REDUCE operator {statement} ENDREDUCE ; |

IF expression THEN statement ELSE statement ENDIF ; |

CASE expression IS {case} OTHERS ARROW statement ENDCASE ;

operator: ADDOP | MULOP

case: WHEN INT_LITERAL ARROW statement

expression:

( expression ) |

expression binary_operator expression |

NOTOP expression |

INT_LITERAL | REAL_LITERAL | BOOL_LITERAL |

IDENTIFIER

binary_operator: ADDOP | MULOP | REMOP | EXPOP | RELOP | ANDOP |OROP

In the above grammar, the red symbols are nonterminals, the blue symbols are terminals and the black punctuation are EBNF metasymbols. The braces denote repetition 0 or more times and the brackets denote optional. You must rewrite the grammar to eliminate the EBNF brace and bracket metasymbols and to incorporate the significance of parentheses, operator precedence and associativity for all operators. Among arithmetic operators the exponentiation operator has highest precedence following by the multiplying operators and then the adding operators. All relational operators have the same precedence. Among the binary logical operators, and has higher precedence than or. Of the categories of operators, the unary logical operator has highest precedence, the arithmetic operators have next highest precedence, followed by the relational operators and finally the binary logical operators. All operators except the exponentiation operator are left associative. The directives to specify precedence and associativity, such as %prec and %left, may not be used Your parser should be able to correctly parse any syntactically correct program without any problem. You must modify the syntactic analyzer to detect and recover from additional syntax errors using the semicolon as the synchronization token. To accomplish detecting additional errors an error production must be added to the function header, another to the variable declaration and a final one to the when clause of the case statement. Your bison input file should not produce any shift/reduce or reduce/reduce errors. Eliminating them can be difficult so the best strategy is not introduce any. That is best achieved by making small incremental additions to the grammar and ensuring that no addition introduces any such errors. An example of compilation listing output containing syntax errors is shown below:

1 — Multiple errors

2

3 function main a integer returns real; Syntax Error, Unexpected INTEGER, expecting ‘:’

4 b: integer is * 2; Syntax Error, Unexpected MULOP

5 c: real is 6.0;

6 begin

7 if a > c then

8 b 3.0; Syntax Error, Unexpected REAL_LITERAL, expecting ‘;’

9 else

10 b = 4.;

11 endif;

12 ; Syntax Error, Unexpected ‘;’, expecting END

Lexical Errors 0

Syntax Errors 4

Semantic Errors 0

listing.cc:

// This file contains the bodies of the functions that produces the compilation// listing

#include

#include

using namespace std;

#include “listing.h”

static int lineNumber;static string error = “”;static int totalErrors = 0;

static void displayErrors();

void firstLine(){lineNumber = 1;printf(“\n%4d “,lineNumber);}

void nextLine(){displayErrors();lineNumber++;printf(“%4d “,lineNumber);}

int lastLine(){printf(“\r”);displayErrors();printf(” \n”);return totalErrors;} void appendError(ErrorCategories errorCategory, string message){string messages[] = { “Lexical Error, Invalid Character “, “”, “Semantic Error, “, “Semantic Error, Duplicate Identifier: “, “Semantic Error, Undeclared ” };

error = messages[errorCategory] + message;totalErrors++;}

void displayErrors(){if (error != “”) printf(“%s\n”, error.c_str());error = “”;}listing.h:

// This file contains the function prototypes for the functions that produce the // compilation listing

enum ErrorCategories {LEXICAL, SYNTAX, GENERAL_SEMANTIC, DUPLICATE_IDENTIFIER,UNDECLARED};

void firstLine();void nextLine();int lastLine();void appendError(ErrorCategories errorCategory, string message);

makefile:

compile: scanner.o parser.o listing.og++ -o compile scanner.o parser.o listing.oscanner.o: scanner.c listing.h tokens.hg++ -c scanner.c

scanner.c: scanner.lflex scanner.lmv lex.yy.c scanner.c

parser.o: parser.c listing.h g++ -c parser.c

parser.c tokens.h: parser.ybison -d -v parser.ymv parser.tab.c parser.ccp parser.tab.h tokens.h

listing.o: listing.cc listing.hg++ -c listing.cc

parser.y:

%{

#include using namespace std;#include “listing.h”

int yylex();void yyerror(const char* message);

%}

%define parse.error verbose

%token IDENTIFIER%token INT_LITERAL%token REAL_LITERAL%token BOOL_LITERAL%token ADDOP MULOP RELOP OROP ANDOP EXPOP REMOP%token BEGIN_ BOOLEAN END ENDREDUCE FUNCTION INTEGER IS REDUCE RETURNS CASE ELSE ARROW%token ENDCASE ENDIF IF OTHERS REAL THEN WHEN NOT%%

function:function_header different_parameter body ;function_header:

FUNCTION IDENTIFIER diff_parameter RETURNS type ‘;’ ;different_parameter:different_parameter variable |;

variable:IDENTIFIER ‘:’ type IS statement_ ;

diff_parameter:

diff_parameter RETURNS type ‘,’ |

parameter ;

parameter:IDENTIFIER ‘:’ type |;

type: INTEGER | REAL | BOOLEAN ;

body:BEGIN_ statement_ END ‘;’ ;

statement_:statement ‘;’ |error ‘;’ ;statement:expression |REDUCE operator reductions ENDREDUCE |IF expression THEN statement_ ELSE statement_ ENDIF |CASE expression IS various_cases OTHERS ARROW statement_ ENDCASE ;reductions:reductions statement_ |;various_cases:various_cases case |;case: WHEN INT_LITERAL ARROW statement_ ;

operator:ADDOP |MULOP | REMOP |EXPOP ;

expression:expression ANDOP relation |expression2;expression2:expression OROP relation |relation;relation:relation RELOP term |term;term:term ADDOP factor |factor ;factor:factor MULOP primary |factor REMOP |exponent ;exponent:factor EXPOP notion |notion;notion:notion NOT primary |primary;primary:'(‘ expression ‘)’ |INT_LITERAL | REAL_LITERAL | BOOL_LITERAL |IDENTIFIER ;%%void yyerror(const char* message){appendError(SYNTAX, message);}int main(int argc, char *argv[]){firstLine();yyparse();lastLine();return 0;}

scanner.l:

/* This file contains flex input file */

%{#include #include

using namespace std;

#include “listing.h”#include “tokens.h”

%}

%option noyywrap

ws [ \t\r]+comment (“//”|”–“).*\nid [A-Za-z](_?[A-Za-z0-9])*real {digit}+\.{digit}*([Ee][+-]?{digit}+)?line [\n]digit [0-9]int {digit}+punc [\(\),:;]%%

{ws} { ECHO; }{comment} { ECHO; nextLine();}{line} { ECHO; nextLine();}”+” { ECHO; return(ADDOP); }”*” { ECHO; return(MULOP); }”=>” { ECHO; return(ARROW); }”<" { ECHO; return(RELOP); }"=" { ECHO; return(RELOP); }"/=" { ECHO; return(RELOP); }">” { ECHO; return(RELOP); }”>=” { ECHO; return(RELOP); }”<=" { ECHO; return(RELOP); }"-" { ECHO; return(ADDOP); }"/" { ECHO; return(MULOP); }"**" { ECHO; return(EXPOP); }"." { ECHO; return(MULOP); }rem { ECHO; return(REMOP); }or { ECHO; return(OROP); }not { ECHO; return(NOTOP); }case { ECHO; return(CASE); }else { ECHO; return(ELSE); }endcase { ECHO; return(ENDCASE); }others { ECHO; return(OTHERS); }endif { ECHO; return(ENDIF); }if { ECHO; return(IF); }real { ECHO; return(REAL); }then { ECHO; return(THEN); }when { ECHO; return(WHEN); }begin { ECHO; return(BEGIN_); }boolean { ECHO; return(BOOLEAN); }end { ECHO; return(END); }endreduce { ECHO; return(ENDREDUCE); }function { ECHO; return(FUNCTION); }integer { ECHO; return(INTEGER); }is { ECHO; return(IS); }reduce { ECHO; return (REDUCE); }returns { ECHO; return(RETURNS); }and { ECHO; return(ANDOP); }true { ECHO; return(BOOL_LITERAL); }false { ECHO; return(BOOL_LITERAL); }{id} { ECHO; return(IDENTIFIER);}{real} {ECHO; return(REAL_LITERAL);}{int} { ECHO; return(INT_LITERAL); }{punc} { ECHO; return(yytext[0]); }. { ECHO; appendError(LEXICAL, yytext); }%%tokens.h:

/* A Bison parser, made by GNU Bison 3.8.2. */

/* Bison interface for Yacc-like parsers in C

Copyright (C) 1984, 1989-1990, 2000-2015, 2018-2021 Free Software Foundation, Inc.

This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with this program. If not, see . */

/* As a special exception, you may make a larger work that contains part or all of the Bison parser skeleton and distribute that work under terms of your choice, so long as that work isn’t itself a parser generator using the skeleton or a modified version thereof as a parser skeleton. Alternatively, if you modify or redistribute the parser skeleton itself, you may (at your option) remove this special exception, which will cause the skeleton and the resulting Bison output files to be licensed under the GNU General Public License without this special exception.

This special exception was added by the Free Software Foundation in version 2.2 of Bison. */

/* DO NOT RELY ON FEATURES THAT ARE NOT DOCUMENTED in the manual, especially those whose name start with YY_ or yy_. They are private implementation details that can be changed or removed. */

#ifndef YY_YY_PARSER_TAB_H_INCLUDED# define YY_YY_PARSER_TAB_H_INCLUDED/* Debug traces. */#ifndef YYDEBUG# define YYDEBUG 0#endif#if YYDEBUGextern int yydebug;#endif

/* Token kinds. */#ifndef YYTOKENTYPE# define YYTOKENTYPE enum yytokentype { YYEMPTY = -2, YYEOF = 0, /* “end of file” */ YYerror = 256, /* error */ YYUNDEF = 257, /* “invalid token” */ IDENTIFIER = 258, /* IDENTIFIER */ INT_LITERAL = 259, /* INT_LITERAL */ REAL_LITERAL = 260, /* REAL_LITERAL */ BOOL_LITERAL = 261, /* BOOL_LITERAL */ ADDOP = 262, /* ADDOP */ MULOP = 263, /* MULOP */ RELOP = 264, /* RELOP */ OROP = 265, /* OROP */ ANDOP = 266, /* ANDOP */ EXPOP = 267, /* EXPOP */ REMOP = 268, /* REMOP */ BEGIN_ = 269, /* BEGIN_ */ BOOLEAN = 270, /* BOOLEAN */ END = 271, /* END */ ENDREDUCE = 272, /* ENDREDUCE */ FUNCTION = 273, /* FUNCTION */ INTEGER = 274, /* INTEGER */ IS = 275, /* IS */ REDUCE = 276, /* REDUCE */ RETURNS = 277, /* RETURNS */ CASE = 278, /* CASE */ ELSE = 279, /* ELSE */ ARROW = 280, /* ARROW */ ENDCASE = 281, /* ENDCASE */ ENDIF = 282, /* ENDIF */ IF = 283, /* IF */ OTHERS = 284, /* OTHERS */ REAL = 285, /* REAL */ THEN = 286, /* THEN */ WHEN = 287, /* WHEN */ NOT = 288, /* NOT */ NOTOP = 289 }; typedef enum yytokentype yytoken_kind_t;#endif

/* Value type. */#if ! defined YYSTYPE && ! defined YYSTYPE_IS_DECLAREDtypedef int YYSTYPE;# define YYSTYPE_IS_TRIVIAL 1# define YYSTYPE_IS_DECLARED 1#endif

extern YYSTYPE yylval;

int yyparse (void);

#endif /* !YY_YY_PARSER_TAB_H_INCLUDED */

This production is not correct:

function:

function_header different_parameter body ;

What is the diferent_parameter there for? Parameters are inside the function header not after it.

Also this one does not look right:

diff_parameter:diff_parameter RETURNS type ‘,’ |parameter ;

Professors notes:

The RETURNS is already in function header. It should not be part of the parameter production.

What you need is something like this:

function_header:

FUNCTION IDENTIFIER optional_parameters RETURNS type ;

Then you need a production for optional_parameters that has two RHSs. One is empty, the other another nonterminal, call it parameters, for example.

Then the parameters production must have a recursive RHS that separates parameters by a comma and a non-recursive RHS that defines a single parameter.

The only other thing is see that obviously looks wrong is you production for not. Not is a unary operator. It should only have one operand.

I have attached the Project Requirements, the Project Approach and the test cases. Please make sure that all the test cases work and match the Project Approach.

Here is the approach I recommend for project 2.
1) First build the skeleton for project 2, run it and be sure that you understand how it works.
2) Replace the lexical analyzer in the project 2 skeleton with your lexical analyzer from project
1. Be sure to remove the main method from your scanner.l. Add the necessary token
declarations for the new tokens. Verify that the project builds correctly at this point. Then
confirm that test cases test1.txt – test4.txt that were provided as test cases for the skeleton
code parse properly.
3) The simplest modification to make first to modify the grammar to include variables and
parameters of the real data type as well as real literals and Boolean literals. Use test5.txt to
test this modification. Shown below is the output that should result when using that test case as
input:
$ ./compile < test5.txt 1 2 3 4 5 6 7 -- Function with a Real Variable and Boolean and Real Literals function main returns boolean; r: real is 5.7; begin true and 2 < 8.E+1 + 1.7E-2 * 7.3E2; end; Compiled Successfully 4) Next, add the if statement to the grammar. Be sure that you understand the difference between the meaning of ; and ';' in the bison input file. The former is the symbol that terminates a production. The latter represents the semicolon symbol in the target language as does the ; in the project specification. Be sure you understand the difference between the statement and the statement_ productions that were provided in the skeleton code. The latter incorporates the semicolon that ends the if statement in the target language and also provides recovery should an error occur within a statement. Use test6.txt to test this modification. Shown below is the output that should result when using that test case as input: $ ./compile < test6.txt 1 2 3 4 5 6 7 8 9 10 -- Conditional expression function main returns integer; begin if 5 + 4 >= 9 then
6 + 9 * 3;
else
8 – 9 / 7;
endif;
end;
Compiled Successfully
5) The case would be best implemented next. The grammar in the specification defines the
language but is not in the form needed for bison. It contains EBNF symbols, that must be
removed. In that part of the grammar, the EBNF braces are used to indicate that a case statement
contains 0 or more when clauses. Because bison does not support these EBNF symbols, a
recursive production must be used instead. Use test7.txt to test this modification. Shown
below is the output that should result when using that test case as input:
$ ./compile < test7.txt 1 2 3 4 5 6 7 8 9 10 11 // Case selection function main returns integer; a: integer is 4 + 2; begin case a is when 1 => 3;
when 2 => (3 + 5 – 5 – 4) * 2;
others => 4;
endcase;
end;
Compiled Successfully
6) The provided skeleton allows an optional, 0 or 1, variable declaration. The requirements state
that 0 or more should be permitted. This modification again requires replacing the EBNF braces
with a recursive production. Use test8.txt to test this modification. Shown below is the output
that should result when using that test case as input:
$ ./compile < test8.txt 1 2 3 4 5 6 7 8 -- Multiple integer variable initialization function main returns integer; b: integer is 5 + 1 - 4; c: integer is 2 + 3; begin b + 1 - c; end; Compiled Successfully 7) The next feature to add is 0 or more parameter declarations in the function header. Because the parameters require comma separators, notice that the grammar is written to indicate that the parameters are optional because in the parameters production must contain at least one. Study how optional elements are included in the grammar by noticing how an optional variable declaration was implemented in the skeleton. Two test cases are provided to test this change. Before using either of them, use one of the early test cases to confirm that your parser still allows no parameters. Then proceed to use, test9.txt, to verify that program with one parameter declaration parses correctly. Shown below is the output that should result when using that test case as input: $ ./compile < test9.txt 1 2 3 4 5 6 -- Single parameter declaration function main a: integer returns integer; begin a + 1; end; Compiled Successfully The next test case, test10.txt contains two parameter declarations. Shown below is the output that should result when using that test case as input: $ ./compile < test10.txt 1 2 3 4 5 6 -- Two parameter declarations function main a: boolean, b: integer returns boolean; begin a and b > 1;
end;
Compiled Successfully
8) The additional arithmetic operators for remainder and exponentiation should be added next.
Notice how the existing operators are implemented in the skeleton code. There must be one
production for each level of precedence. Because the remainder operator has the same
precedence as the multiplying operators, it should be included as another right-hand side to the
existing production. But because the exponentiation operator has higher precedence a production
must be introduced. Because that operator is right associative, its production must be right
recursive. In the Course Resources area of the classroom you will find Module 1 from CMSC
330. You may want to read section II-B if you need a better understanding of how to construct a
grammar so that it produces the correct parse tree to account for precedence and associativity.
Then proceed to use, test11.txt, to verify that program containing every arithmetic operator
parses correctly. Shown below is the output that should result when using that test case as input:
$ ./compile < test11.txt 1 2 3 4 5 6 // Arithmetic operators function main returns integer; begin 9 + 2 - (5 - 1) / 2 rem 3 * 3 ** 1 ** 2; end; Compiled Successfully 9) The additional logical operators, which include the or and not operators should be added next. Each has a separate precedence level. The or operator has the lowest precedence of all operators and not has the highest. So, two new productions must be added to the grammar. Shown below is the output that should result when using that test case as input: $ ./compile < test12.txt 1 2 3 4 5 -- Relational and logical operators function main returns boolean; begin 5 > 8 and 3 = 3 or 9 < 1 and not (3 /= 7) or 6 = 9 or not true and not not false; 6 end; Compiled Successfully 10) At this point your parser should contain the complete grammar for the language. As a final check, use test cases test13.txt, which contains a nested if together with most elements of the language and test14.txt, which contains a nested case statement. Shown below is the output that should result when using test13.txt as input: $ ./compile < test13.txt 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 -- Comprehensive test with nested if function main a: integer, b: boolean, c: real returns integer; d: integer is 8; e: real is 3.75; f: boolean is true and not b; begin if a > 5 and a < 1 and c = 5. or c /= 8.E4 or f then if c >= 7.E-2 and c a * 2 / d ** 2;
when 2 => a + 5.E+2 – b;
when 3 =>
case d is
when 1 => a rem 2;
others => 9.1E-1;
14
15
16
17
18
endcase;
when 4 => a / 2 – c;
others => a + 4.7 * b;
endcase;
end;
Compiled Successfully
11) At this point, you are ready to implement the error recovery portion of the program. Verify
first that test case syntax1.txt that was include with the project 2 test data produces the correct
output. Then modify the grammar so that errors in the function header will be properly recovered
from. You will need to introduce an additional production that includes the error token. You
should use the statement_ production in the skeleton code as a model. Once you have
implemented the error recovery production for the function header, use test case syntax2.txt to
test it. Shown below is the output that should result when using syntax2.txt as input:
$ ./compile < syntax2.txt 1 -- Error in function header, missing colon 2 3 function main a integer returns integer; Syntax Error, Unexpected INTEGER, expecting ':' 4 b: integer is 3 * 2; 5 begin 6 if a 5 then 6 a * 3; 7 else 8 2 + a; 9 10 11 12 13 14 15 16 17 endif; c: real is 3.5; begin if a a 2; Syntax Error, Unexpected INT_LITERAL, expecting ';' 7 when 2 => 5;
8
endcase;
Syntax Error, Unexpected ENDCASE, expecting WHEN or OTHERS
9 end;
Lexical Errors 0
Syntax Errors 2
Semantic Errors 0
The fact that the second error, the one indicating that the others clause is missing, confirms that
recovery from the first error message has occurred.
14) As a final test use test case syntax5.txt, which contains a variety of syntax errors. Shown
below is the output that should result when using that test case as input:
$ ./compile < syntax5.txt 1 // Multiple errors 2 3 function main a integer returns real; Syntax Error, Unexpected INTEGER, expecting ':' 4 b: integer is * 2; Syntax Error, Unexpected MULOP 5 c: real is 6.0; 6 begin 7 if a > c then
8
b + / 4.;
Syntax Error, Unexpected MULOP
9
else
10
case b is
11
when => 2;
Syntax Error, Unexpected ARROW, expecting INT_LITERAL
12
when 2 => c;
13
endcase;
Syntax Error, Unexpected ENDCASE, expecting WHEN or OTHERS
14
endif;
15 end;
Lexical Errors 0
Syntax Errors 5
Semantic Errors 0
If you have implemented all the required error recovery, your compiler should detect all five
syntax errors.
All of the test cases discussed above are included in the attached .zip file.
You are certainly encouraged to create any other test cases that you wish to incorporate in your
test plan. Keep in mind that your parser should parse all syntactically correct programs, so I
recommend that you choose some different test cases as a part of your test plan. I may use a
comparable but different set of test cases when I test your projects.
CMSC 430 Project 2
The second project involves modifying the syntactic analyzer for the attached compiler by
adding to the existing grammar. The full grammar of the language is shown below. The
highlighted portions of the grammar show what you must either modify or add to the existing
grammar.
function:
function_header {variable} body
function_header:
FUNCTION IDENTIFIER [parameters] RETURNS type ;
variable:
IDENTIFIER : type IS statement
parameters:
parameter {, parameter}
parameter:
IDENTIFIER : type
type:
INTEGER | REAL | BOOLEAN
body:
BEGIN statement END ;
statement:
expression ; |
REDUCE operator {statement} ENDREDUCE ; |
IF expression THEN statement ELSE statement ENDIF ; |
CASE expression IS {case} OTHERS ARROW statement ENDCASE ;
operator:
ADDOP | MULOP
case:
WHEN INT_LITERAL ARROW statement
expression:
( expression ) |
expression binary_operator expression |
NOTOP expression |
INT_LITERAL | REAL_LITERAL | BOOL_LITERAL |
IDENTIFIER
binary_operator: ADDOP | MULOP | REMOP | EXPOP | RELOP | ANDOP | OROP
In the above grammar, the red symbols are nonterminals, the blue symbols are terminals and the
black punctuation are EBNF metasymbols. The braces denote repetition 0 or more times and the
brackets denote optional.
You must rewrite the grammar to eliminate the EBNF brace and bracket metasymbols and to
incorporate the significance of parentheses, operator precedence and associativity for all
operators. Among arithmetic operators the exponentiation operator has highest precedence
following by the multiplying operators and then the adding operators. All relational operators
have the same precedence. Among the binary logical operators, and has higher precedence than
or. Of the categories of operators, the unary logical operator has highest precedence, the
arithmetic operators have next highest precedence, followed by the relational operators and
finally the binary logical operators. All operators except the exponentiation operator are left
associative. The directives to specify precedence and associativity, such as %prec and %left,
may not be used
Your parser should be able to correctly parse any syntactically correct program without any
problem.
You must modify the syntactic analyzer to detect and recover from additional syntax errors using
the semicolon as the synchronization token. To accomplish detecting additional errors an error
production must be added to the function header, another to the variable declaration and a final
one to the when clause of the case statement.
Your bison input file should not produce any shift/reduce or reduce/reduce errors. Eliminating
them can be difficult so the best strategy is not introduce any. That is best achieved by making
small incremental additions to the grammar and ensuring that no addition introduces any such
errors.
An example of compilation listing output containing syntax errors is shown below:
1 — Multiple errors
2
3 function main a integer returns real;
Syntax Error, Unexpected INTEGER, expecting ‘:’
4
b: integer is * 2;
Syntax Error, Unexpected MULOP
5
c: real is 6.0;
6 begin
7
if a > c then
8
b 3.0;
Syntax Error, Unexpected REAL_LITERAL, expecting ‘;’
9
else
10
b = 4.;
11
endif;
12 ;
Syntax Error, Unexpected ‘;’, expecting END
Lexical Errors 0
Syntax Errors 4
Semantic Errors 0
You are to submit two files.


The first is a .zip file that contains all the source code for the project. The .zip file
should contain the flex input file, which should be a .l file, the bison file, which should
be a .y file, all .cc and .h files and a makefile that builds the project.
The second is a Word document (PDF or RTF is also acceptable) that contains the
documentation for the project, which should include the following:
a. A discussion of how you approached the project
b. A test plan that includes test cases that you have created indicating what aspects
of the program each one is testing and a screen shot of your compiler run on that
test case
c. A discussion of lessons learned from the project and any improvements that could
be made
Grading Rubric
Criteria
Meets
70 points
Parses all syntactically correct
programs (25)
Does not parse all syntactically correct
programs (0)
Productions correctly implement
precedence and associativity (10)
Productions do not correctly
implement precedence and
associativity (0)
Grammar contains no shift/reduce or
reduce/reduce errors (5)
Grammar contains shift/reduce or
reduce/reduce errors (0)
Detects and recovers from all programs
with single syntax errors (20)
Does not detect and recover from
errors in the function header (0)
Detects and recovers from a program
with multiple syntax errors (10)
Does not detect and recover from
multiple errors (0)
Functionality
15 points
Test Cases
0 points
Includes test cases that test all
grammar productions (6)
Does not include test cases that test all
grammar productions (0)
Includes test cases that test errors in all
productions (6)
Does not include test cases that test
errors in all productions (0)
Includes test case with multiple errors
(3)
Does not include test case with
multiple errors (0)
15 points
Documentation
Does Not Meet
0 points
Discussion of approach included (5)
Lessons learned included (5)
Comment blocks with student name,
project, date and code description
included in each file (5)
0 points
Discussion of approach not included (0)
Lessons learned not included (0)
Comment blocks with student name,
project, date and code description not
included in each file (0)

Calculate your order
275 words
Total price: $0.00

Top-quality papers guaranteed

54

100% original papers

We sell only unique pieces of writing completed according to your demands.

54

Confidential service

We use security encryption to keep your personal data protected.

54

Money-back guarantee

We can give your money back if something goes wrong with your order.

Enjoy the free features we offer to everyone

  1. Title page

    Get a free title page formatted according to the specifics of your particular style.

  2. Custom formatting

    Request us to use APA, MLA, Harvard, Chicago, or any other style for your essay.

  3. Bibliography page

    Don’t pay extra for a list of references that perfectly fits your academic needs.

  4. 24/7 support assistance

    Ask us a question anytime you need to—we don’t charge extra for supporting you!

Calculate how much your essay costs

Type of paper
Academic level
Deadline
550 words

How to place an order

  • Choose the number of pages, your academic level, and deadline
  • Push the orange button
  • Give instructions for your paper
  • Pay with PayPal or a credit card
  • Track the progress of your order
  • Approve and enjoy your custom paper

Ask experts to write you a cheap essay of excellent quality

Place an order