Programming Language and Semantic Rules Project

User Generated

wubaalubc16

Programming

Description

Choose a programming language with which you are familiar and identify one of the semantic rules of that language. Give an example of a program in that language that violates that rule. Post a screen shot showing the error message that the compiler for that language would generate for your program example.

Then review the requirements for project 4. Select one of the semantic errors that you are to detect in project 4 and provide a test case that will detect it.

Unformatted Attachment Preview

CMSC 430 Project 4 The fourth project involves modifying the semantic analyzer for the attached compiler by adding checks for semantic errors. The static semantic rules of this language are the following: Variables and parameter names have local scope. The scope rules require that all names be declared and prohibit duplicate names within the same scope. The type correspondence rules are as follows:           Boolean expressions cannot be used with arithmetic or relational operators. Arithmetic expressions cannot be used with logical operators. Reductions can only contain numeric types. Only integer operands can be used with the remainder operator. The two statements in an if statement must match in type. No coercion is performed. All the statements in a case statement must match in type. No coercion is performed. The type of the if expression must be Boolean. The type of the case expression must be Integer A narrowing variable initialization or function return occurs when a real value is being forced into integer. Widening is permitted. Boolean types cannot be mixed with numeric types in variable initializations or function returns. Type coercion from an integer to a real type is performed within arithmetic expressions. You must make the following semantic checks. Those highlighted in yellow are already performed by the code that you have been provided, although you are must make minor modifications to account for the addition of real types and the need to perform type coercion and to handle the additional arithmetic and logical operators.               Using Boolean Expressions with Arithmetic Operator Using Boolean Expressions with Relational Operator Using Arithmetic Expressions with Logical Operator Reductions containing nonnumeric types Remainder Operator Requires Integer Operands If-Then Type Mismatch Case Types Mismatch If Condition Not Boolean Case Expression Not Integer Narrowing Variable Initialization Variable Initialization Mismatch Undeclared Variable Duplicate Variable Narrowing Function Return This project requires modification to the bison input file, so that it defines the additional semantic checks necessary to produce these errors and addition of functions to the library of type checking functions already provided in types.cc. You must also make some modifications to the functions provided. You need to add a check to the checkAssignment function for mismatched types in the case that Boolean and numeric types are mixed. You need to also add code to the checkArithmetic function to coerce integers to reals when the types are mixed and the error message must be modified to indicate that numeric rather than only integer types are permitted. The provided code includes a template class Symbols that defines the symbol table. It already includes a check for undeclared identifiers. You need to add a check for duplicate identifiers. Like the lexical and syntax errors, the compiler should display the semantic errors in the compilation listing, after the line in which they occur. An example of compilation listing output containing semantic errors is shown below: 1 -- Test of Multiple Semantic Errors 2 3 function test a: integer returns integer; 4 b: integer is 5 if a + 5 then 6 2; 7 else 8 5; 9 endif; Semantic Error, If Expression Must Be Boolean 10 c: real is 9.8 - 2 + 8; 11 d: boolean is 7 = f; Semantic Error, Undeclared f 12 begin 13 case b is 14 when 1 => 4.5 + c; 15 when 2 => b; Semantic Error, Case Types Mismatch 16 others => c; 17 endcase; 18 end; Lexical Errors 0 Syntax Errors 0 Semantic Errors 3 You are to submit two files. 1. 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. 2. 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 Functionality Meets Does Not Meet 70 points 0 points Generates semantic error when a remainder operator has non-integer operands (10) Does not generate semantic error when a remainder operator has noninteger operands (0) Generates semantic error when if and then types don't match (10) Does not generate semantic error when if and then types don't match (0) Generates semantic error when case types don't match (10) Does not generate semantic error when case types don't match (0) Generates semantic error when if condition is not Boolean (10) Does not generates semantic error when if condition is not Boolean (0) Generates semantic error when case expression is not integer (10) Does not generate semantic error when case expression is not integer (0) Generates semantic error on narrowing initialization (10) Does not generate semantic error on narrowing initialization (0) Generates semantic error for duplicate variables (10) Does not generate semantic error for duplicate variables (0) 15 points Test Cases Includes test cases that test all type checking errors (10) Does not Include test cases that test all type checking errors (0) Includes test cases that test all symbol table errors (3) Does not include test cases that test all symbol table errors (0) Includes test case with multiple errors (2) Does not include test case with multiple errors (0) 15 points Documentation 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) Here is the approach I recommend for project 4. 1) Although you have the option of keeping the interpreter from project 3 in the final project, it is a slightly more complicated approach. Unless you are an experienced C++ programmer, it will be simpler to take your project 2 implementation and begin by incorporating what is in the project 4 skeleton, much like what you should have done for project 3. Because your project 2 has additional productions, be sure to include them in your %type declaration. You are likely to have some type clash warnings at this point. You initially should be able to ignore them. Once you complete the project, they should all be resolved, however. At this point, you should verify that the test cases provided with the project 4 skeleton, semantic1.txt - semantic6.txt, produce the same output as before. A good starting point would be to incorporate real types. To accomplish that you will need to modify the Types enumeration in types.h, assign an attribute to real literal tokens in scanner.l and modify the type production in parser.y. To verify that your program accepts real types, use valid1.txt. Shown below is the output that should result when using that test case as input: $ ./compile < valid1.txt 1 2 3 4 5 6 7 8 -- Program with a Real Variable function main returns real; a: real is 4.5; begin a; end; Compiled Successfully The fact that it compiles successfully confirms that real types have been added. 2) The next requirement to implement is to ensure that type coercion from an integer to a real type is performed within arithmetic expressions. That will require that you modify the checkArithmetic function so that it returns a real type when one operand is integer and the other is real. It should, of course, still return an integer type when both types are integer. To verify that your program performs type coercion, use valid2.txt. Shown below is the output that should result when using that test case as input: $ ./compile < valid2.txt 1 2 3 4 5 6 7 8 -- Program with a Real Variable function main returns real; a: real is 4 + 4.5; begin a; end; Compiled Successfully The fact that it compiles successfully confirms that type coercion has been incorporated. 3) Next, fully incorporate the Boolean type by assigning an attribute to the Boolean literals tokens in scanner.l. Also, generalize the error message that is produced when mixing Booleans with arithmetic operators and arithmetic expressions that contain real values to indicate that a numeric type is required rather than just an integer type. Use semantic7.txt to test this modification. Shown below is the output that should result when using that test case as input: $ ./compile < semantic7.txt 1 -- Using Boolean Literal with Arithmetic Operator 2 3 function main returns real; 4 a: real is 8.7 + false; Semantic Error, Numeric Type Required 5 begin 6 9.5 + true; Semantic Error, Numeric Type Required 7 end; Lexical Errors 0 Syntax Errors 0 Semantic Errors 2 The fact that an error message has been generated confirms that Boolean literals have been given a type. Also, notice the error message has been generalized to allow for both integer and real types. 4) Because the skeleton did not include productions for all operators, you need to add semantic actions to those productions. The exponentiation operator is one of them. Use semantic8.txt to test this modification. Shown below is the output that should result when using that test case as input: $ ./compile < semantic8.txt 1 -- Using Boolean Expression with Exponentiation Operator 2 3 function main returns integer; 4 begin 5 5 ** (1 > 0); Semantic Error, Numeric Type Required 6 end; 7 Lexical Errors 0 Syntax Errors 0 Semantic Errors 1 The fact that an error message has been generated confirms that production has been successfully modified. 5) The or is another one of them. Use semantic9.txt to test this modification. Shown below is the output that should result when using that test case as input: $ ./compile < semantic9.txt 1 -- Using Arithmetic Expression with Logical Or Operator 2 3 function main returns integer; 4 begin 5 9 or 6 < 3; Semantic Error, Boolean Type Required 6 end; Lexical Errors 0 Syntax Errors 0 Semantic Errors 1 The fact that an error message has been generated confirms that production has been successfully modified. 6) The not is the last one of them. Use semantic10.txt to test this modification. Shown below is the output that should result when using that test case as input: $ ./compile < semantic10.txt 1 -- Using Arithmetic Expression with Logical Not Operator 2 3 function main returns integer; 4 begin 5 not 3; Semantic Error, Boolean Type Required 6 end; Lexical Errors 0 Syntax Errors 0 Semantic Errors 1 The fact that an error message has been generated confirms that production has been successfully modified. This change should also eliminate one of the type clashes from bison. 7) At this point you are ready to incorporate the code to check for the remaining semantic errors. A good first choice would be to implement the test that determines whether the types on the rem operator are integers. Adding a new function to types.h and types.cc is best, given that this check requires more than a single line of code. Use semantic11.txt to test this modification. Shown below is the output that should result when using that test case as input: $ ./compile < semantic11.txt 1 -- Mixing Real literals with the Remainder Operator 2 3 function main returns real; 4 begin 5 4 rem 4.8; Semantic Error, Remainder Operator Requires Integer Operands 6 end; Lexical Errors 0 Syntax Errors 0 Semantic Errors 1 8) The two semantic checks on the if statement would be a good next step. The first required check is to ensure that the type of the expression is Boolean. Both of these checks can be accomplished by adding a semantic action on the if statement and ideally a new function in types.cc. Use semantic12.txt to test the first of these two.. Shown below is the output that should result when using that test case as input: $ ./compile < semantic12.txt 1 -- If Condition Not Boolean 2 3 function main returns integer; 4 b: integer is 7 * 2; 5 begin 6 if 3 + 6 then 7 b + 3; 8 else 9 b * 4; 10 endif; Semantic Error, If Expression Must Be Boolean 11 end; Lexical Errors 0 Syntax Errors 0 Semantic Errors 1 9) The other check is to determine whether the types on the two parts of an if statement match. Use semantic13.txt to test this modification. Shown below is the output that should result when using that test case as input: $ ./compile < semantic13.txt 1 -- Conditional Expression Type Mismatch 2 3 function main returns integer; 4 begin 5 if 6 < 0 then 6 5 + 3.0; 7 else 8 8 * 4; 9 endif; Semantic Error, If-Then Type Mismatch 10 end; Lexical Errors 0 Syntax Errors 0 Semantic Errors 1 10) The next best pair of checks to implement are the ones that check whether a variable initialization or function return are narrowing. Both require changing the checkAssignment function. Use semantic14.txt to test the check for narrowing variable initialization. Shown below is the output that should result when using that test case as input: $ ./compile < semantic14.txt 1 -- Narrowing Variable Initialization 2 3 function main returns integer; 4 b: integer is 5 * 2.5; Semantic Error, Illegal Narrowing Variable Initialization 5 begin 6 b + 1; 7 end; Lexical Errors 0 Syntax Errors 0 Semantic Errors 1 11) You should be able to use the same function to check a narrowing function return by adding a similar semantic action on the top level production for the whole function. Be sure that you have declared that the function_header and body productions carry a type attribute if your receive an error indicating that they have no declared type. In addition both require semantic actions that pass the type information up the parse tree. Use semantic15.txt to test the check for a narrowing function return. Shown below is the output that should result when using that test case as input: $ ./compile < semantic15.txt 1 -- Narrowing Function Return 2 3 function main returns integer; 4 b: integer is 6 * 2; 5 begin 6 if 8 < 0 then 7 b + 3.0; 8 else 9 b * 4.6; 10 endif; 11 end; Semantic Error, Illegal Narrowing Function Return Lexical Errors 0 Syntax Errors 0 Semantic Errors 1 12) The check for duplicate variables is a good one to incorporate next. Because the symbol table already contains a function to look up identifiers, no modification to the symbol table code is required. Instead the semantic action for variable declarations can be modified to first check whether the identifier is in the symbol table, and if so, generate a duplicate identifier error. Use semantic16.txt to test the check for a duplicate identifier. Shown below is the output that should result when using that test case as input: $ ./compile < semantic16.txt 1 -- Duplicate Identifier 2 3 function main returns integer; 4 b: integer is 4 * 2; 5 b: boolean is true; Semantic Error, Duplicate Identifier: b 6 begin 7 if 8 d; 10 when 2 => true; 11 others => false; 12 endcase; Semantic Error, Case Expression Not Integer 13 end; Semantic Error, Type Mismatch on Function Return Lexical Errors 0 Syntax Errors 0 Semantic Errors 2 14) The last check to implement is the one that checks whether all the types of all the when clauses of the case statement match. The implementation is similar to what was needed in project 3. In this case, a sentinel value again is needed. This time it indicates whether an initial type has been determined. Adding another enumeration literal to the Types enumeration will provide one. It should become the attribute of the empty production in the definition of the list of when clauses. No inherited attributes are needed to implement this check. Be sure all productions connected to this statement are declared in the %type declaration. At this point, all type clashes should be eliminated. Use semantic18.txt to test this semantic error. Shown below is the output that should result when using that test case as input: $ ./compile < semantic18.txt 1 -- Test of Case Types Mismatch 2 3 function main returns integer; 4 b: integer is 9 - 2 + 8; 5 c: real is 9.5; 6 d: boolean is 7 = 3; 7 begin 8 case b is 9 when 1 => c; 10 when 2 => true; Semantic Error, Case Types Mismatch 11 others => false; 12 endcase; 13 end; Lexical Errors 0 Syntax Errors 0 Semantic Errors 1 15) As a final test, use semantic19.txt to test a program that contains multiple semantic errors. Shown below is the output that should result when using that test case as input: $ ./compile < semantic19.txt 1 -- Test of Multiple Semantic Errors 2 3 function main returns integer; 4 b: integer is 5 if 6 + 5 then 6 2; 7 else 8 5; 9 endif; Semantic Error, If Expression Must Be Boolean 10 c: real is 9.8 - 2 + 8; 11 d: boolean is 7 = f; Semantic Error, Undeclared f 12 begin 13 case b is 14 when 1 => 4.5 + c; 15 when 2 => b; Semantic Error, Case Types Mismatch 16 others => c; 17 endcase; 18 end; Lexical Errors 0 Syntax Errors 0 Semantic Errors 3 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 compiler should produce the correct semantic error for all programs that contain them, 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.
Purchase answer to see full attachment
User generated content is uploaded by users for the purposes of learning and should be used following Studypool's honor code & terms of service.

Explanation & Answer

Please view explanatio...

Related Tags