代写CS259 Coursework 2024帮做Java编程

2024.03.24 - 首页 >> C/C++编程

Coursework 2024

(20 % of CS259 assessment)

[Due by 12 PM, April 25, 2024]

1 Language Description

PLM (Programming Language of the Moment) is a language that allows users to write code that computes non-negative integers. A PLM program consists of several lines of code. The inal line only contains the end-of-ile character. Every other line either deines a single function or is a single comment, but not both.

1.1 Function deinitions

A function defnition must comprise exactly the seven elements speciied below. They must occur in a single line, exactly in the order listed below, and must be separated from each other by exactly one space character.

. keyword DEF

. function name

. parameter name

. left brace

. function body

. right brace

. semicolon

For instance the function that returns its argument incremented by 4 can be deined using the following syntax.

DEF ADDFOUR x f x+4 g ;

ADDFOUR is the function name, x is the parameter name and x+4 is the function body.

1.2 Comments

Every comment must begin with /* and end with */, but have no intervening */.

1.3 Additional Conditions

Additionally, PLM code must satisfy all Additional Conditions described below.

1. The character D from DEF must be theirst character on each line with a function deinition.

2. The semicolon in every function deinition must be followed immediately by the end-of-line character.

3. Function names are non-empty strings of upper-case letters (A-Z) with one exception. The word DEF is a keyword and a reserved word in the language. Consequently, DEF cannot be used as the name of a function.

4. Parameter names are non-empty strings of lower-case letters (a-z).

5. The only exception to the rule stated in Section 1.1 is the function with name MAIN. No parameter name is allowed after MAIN, i.e. MAIN must be followed by one space and then the left brace after which the same requirements from Section 1.1 apply.

6. There can be no whitespace inside the function body, but remember that the body must be separated from the enclosing braces by one space on each side.

7. The function body is an arithmetic expression built from non-negative integers, the asso- ciated parameter name as well as function calls. The only arithmetic operations allowed are addition and multiplication. Parentheses are not allowed, except in function calls (see next point). The function body must be non-empty. You may assume that numbers do not have leading zeros.

8. Function calls have to refer to functions that have been deined as part of the same program. Function deinitions are listed in no particular order. It is possible for a function body to make calls to functions deined later in the program. Functions can also call themselves.

9. Any function diferent from MAIN can be called. Function calls are made by mentioning the relevant function name along with an argument enclosed in a pair of parentheses, e.g. ADDFOUR(3+5*6). No Whitespace can occur between the parentheses. The argument must satisfy the same constraints as function bodies. That is, it must be anon-empty arithmetic expression built from addition, multiplication, non-negative integers, the parameter name of the function that is making the call, as well as calls to other functions.

10. Every program must deine the MAIN function.

11. No function can be deined twice.

12. No characters other than the speciic ASCII characters referenced so far, are allowed.

13. A comment can use any ASCII character referenced so far.

14. Each line that has a comment must start with the delimiter /*. The delimiter */ that ends

a comment must be followed by the end-of-line character.

Here are some examples of PLM programs.

1. Example 1

DEF MAIN { 1+ADDFOUR(2+ADDFOUR(3)) } ;

/*Thisisacomment*/

DEF ADDFOUR x { x+4 } ;

2. Example 2

DEF ABCD xyz { BCD(xyz) } ;

DEF BCD xy { 2*CD(xy) } ;

/*DEF MAIN { ABCD(1) } ;*/

DEF CD x { D(x)+EF(x) } ;

DEF D x { 10 } ;

DEF EF x { 10*x } ;

DEF MAIN { ABCD(1) } ;

3. Example 3

DEF QQ yy { 2*PP(yy)+3*QQ(yy) } ;

DEF PP xx { QQ(xx)+3 } ;

/*/

DEF MAIN { PP(0)+3 } ;

Here are some examples of pieces of code that do not constitute a legitimate PLM program.

1. Non-example 1

DIF MAIN { 1+ADDFOUR(2+ADDFOUR(3)) } ;

This is not a PLM program because DIF is used instead of DEF.

2. Non-example 2

/*DEF MAIN { ABCD(1) }*/

No MAIN function.

3. Non-example 3

DEF P2P xXx { 3*Q()+R(6,Q(5)) };

/Thisisacomment/

This is not a PLM program due to any one of the following reasons.

(a) The function name P2P contains a number but function names are only allowed to contain upper-case letters.

(b) The parameter name xXx contains an upper-case letter, which is not allowed.

(d) The MAIN function is missing.

(e) There is no space between } and ;.

(f) The argument in the call to Q is empty.

(g) The argument in the call to R contains a ‘,’ which is not allowed.

(h) Incorrect comment delimiters.

2 Tasks

PLM programs can be executed by running the function body of MAIN. This may result in calls to other functions, which may in turn call further functions and so on. When a function call is made, we assume that the argument is always evaluated irst and the value is then substituted for all occurrences of the corresponding parameter in the function body. Sometimes this will produce a result: the irst two examples of PLM programs we saw earlier return 14 and 40 respectively. In cases when there are circular dependencies between functions (eg. Example 3), the program will not terminate. For the purposes of evaluation, we assume that multiplication takes precedence over addition. Function deinitions within comment delimiters are ignored.

2.1 Task one

Implement a parser (along with a lexer) that recognizes PLM programs.

2.2 Task Two

Extend the parser to an interpreter so that it can determine whether the input program returns a result or not. If the former is the case, the result (a non-negative integer) should be printed out.

3 I/O Speciications

Your parser should read the input from System. in. System. out should be used for output. Parsing errors should be reported on System. err. You must provide exactly one error message which gives exactly one reason (out of possibly many reasons) why the input is not a PLM program. More details follow.

. If the input is a valid PLM program, then two lines must printed out to System. out: the irst line only contains the word PASS and the second line must contain information about the results, as explained in the next sentence. If the program evaluates to a number, then the number should be printed out on the second line. Otherwise, the line should read LOOP.

. If the input is not a PLM program, only a single line with FAIL should be printed out to the standard output stream. Two lines must printed out to System. err:

– the irst line only contains the line number in the input where a violation has been identiied, and

– the second line gives an error message clearly describing this violation.

When the violation described is a missing MAIN function, then the line number of the violation should be 0. You are not allowed to simply use default javacc messages regarding uncaught exceptions as a reason for the input not being a PLM program. Consequently, you are expected to decode the javacc exceptions to provide your own error message.

Here is the expected output for the examples given earlier.

Example 1

PASS

Example 2

PASS

Example 3

PASS

LOOP

Nonexample 1

FAIL

Nonexample 2

FAIL

Here is a sample of acceptable outputs to the error stream.

Nonexample 1

Missing keyword DEF

Nonexample 2

Missing MAIN function

4 Further Information

4.1 Submission instructions

Submit a single ile named Assignment. jj containing your speciication via Tabula. The ile Assignment. jj must cause javacc to generate your parser Assignment. java. Compilation should work on DCS machines using the commands:

javacc Assignment. jj

javac *. java

For reading an input ile called test. txt, the command

java Assignment < test. txt

should produce the required output. The output of the parser should just appear on screen, it should not be sent to another ile. To test your solution with the input ile test. txt, invoke

java Assignment < test. txt > output. txt 2>err. txt

and check if the contents of output.txt and err.txt conform to the speciications regarding the standard output and error messages respectively.

4.2 Evaluation policy and constraints

Task One is worth 50% and Task Two is worth 30%. The remaining 20% is for readable and maintainable code. Comments and indentation improve readability. Moreover, 30% of the Task One score is for correctly determining whether or not the input is a PLM program and the remaining 70% is for accurate error reporting as described in the I/O speciications.

. The evaluation procedure will use JavaCC 7.0.10, so it is your responsibility to make sure that your submission compiles as intended with this version.

. The testing of your solutions will use exactly the set of the compilation and execution commands described in Section 4.1. So please make sure that you stick to all of the speciications (they are case sensitive) exactly. Moreover, please make sure that you send each output to the correct stream.

. Please base your submission on the template ile available on the module page. In partic- ular, the parser name must remain unchanged.

. Any change that must be made to the ile name to rectify compilation/execution issues during evaluation will incur a penalty of -20%.

. You may not use JJTree for this coursework.

. You are not allowed to employ StackOverFlowError to detect loops in the input program. Loops must be explicitly detected by your parser/evaluator and the relevant portion of your code appropriately annotated with comments.

. You may work with 32 bit signed integers and you may assume that each input ile has at most 50 lines of at most 100 characters each.

. Testing of Task Two is fully automated. In Task One, your parser’s recognition of valid PLM programs is also fully automated. Only the error messages for invalid tests and your code documentation will be evaluated manually.

. No changes in your submitted code will be permitted after the coursework deadline has passed. This includes minor changes such as adding/removing/modifying a single character in your code. The department’s standard late submission policy applies unless an extension has been granted.

. If you submit the wrong ile and are unable to resubmit because the deadline has passed, you should contact [email protected] to have the original submission removed so that you are able to upload a new submission. This will incur a late penalty. Late penalties will not be waived unless via a Mitigating Circumstances panel decision.

4.3 Feedback Format

On Tabula, you will receive the following feedback:

Recognition-percentage: x , Evaluation-percentage: y , Error- identiication-percentage: z , Documentation-percentage: w , Task 1 percentage: p , Task 2 percentage: q , Additional feedback: r

The values x, y , z indicate the fraction of tests on which your code performed as required in recognizing PLM programs, interpreting/evaluating them, and producing the right error mes- sages, respectively. The coursework marks are obtained by weighting p, q and w according to the coursework speciication (50/30/20). Task 1 consists of recognizing valid PLM programs (x) and producing appropriate error messages for invalid problems (z) weighted 30/70. Task 2 is just the percentage of successfully interpreted inputs with rounding.

For submission with compilation errors, I will note this in the “additional feedback” ield.

For more speciic feedback (e.g., insight into the kind of tests your code failed), you can write me to me and I will be happy to discuss this with you.

5 Suggestions

You may discuss with fellow students the general workings of javacc or parsing, but you are not allowed to collaborate on the solution. The University of Warwick takes plagiarism seriously, and penalties will be incurred if any form of plagiarism is detected. Copying, or basing your work on, solutions written by people who have not taken this course is also considered plagiarism. This includes material that has been downloaded from the internet.

BACKUP: Please keep a copy of everything you submit.

STUDY: Inspect the MyParserTokenManager, MyParserConstants, Token, ParseException, TokenMgrError classes carefully.

WINDOWS USERS: Please pay attention to the fact that Windows uses “nrnn” for line breaks, while the iles that will be used to test your code will use “nn” . So, please make sure that you follow the next suggestion.

BEFORE SUBMISSION: Make sure your code functions correctly on the sample tests provided on the module page and on the DCS machines. Do not just copy paste code from this speciication document for your testing as you may lose some formatting (e.g., miss whitespaces or some end-of-line characters).

POST SUBMISSION: As soon as you submit, please download your submission and test it as described in Section 4.1 in order to make sure that the version you submitted is the one you intended to submit.

ASK: If you have any questions, please ask the module organizer.