Remarks of question #1: [1] marks distribution * * * The pattern a b c --- 8 pts The correct constraint --- 2 pts p q r a b c where p,q,r >= 2 p q r w x y where p,q,r >= 2 (Another Version) ********************************************************************* (* These answers below are also accepted *) 1) a.....ab.....bc.....c N.B. aa....abb....bcc....c (-1 marks, it is "read" that the string must have at least 3 a's, more or less a careless mistake) 2) contains 3 substrings The first part is a list of "a"s, i.e. aa......, where ther length is at least 2, it is follwed by a list of "b"s, i.e. bb......, where ther length is at least 2, it is follwed by a list of "c"s, i.e. cc......, where ther length is at least 2 N.B. In alternative answer 2, you must explicitly describe the patterns of each substring and the order of substrings must be described as well. **************************************************************** [2] Problems Encounterd - Many students (about 1/5 of them) describe the rules instead of the language generated: E.g. ---------------------------------------------------------------- :: a | a is a non-terminal where it is left associative, it can be a terminal "a" followed by a non-terminal or a terminal "a" . . . ( 0 Marks for this type of answer) ---------------------------------------------------------------- For answering this question, the language generated should get rid of All the non-terminal. Also, to describe the language generated, it refers to the pattern and the properties (constraint) of the set of strings which can be derived by the Rules (That begins with the starting symbol). The problem is probably due to confusion of "Grammar","Rules" and "Language" - Wrong interpretation about the properties of the language p q r { s: a b c where p,q,r >= 1 (p,q,r can be any value)} Will deduct 2 marks, as abc can also be in the Language, which is a wrong Interpretation to the grammar. Comments: **************************************************** The mistake of the students is mainly due to wrong interpretation of the question (probably due to problems in English). Also, such kind of language m n a b is not much discussed in the tutorial section, more training exercise should be done for this case. ----------------------------------------------------------------------------------------------------------------------------------------------- Remarks for question #2: [1] marks distribution over sub-parts are indicated in curly brackets {}: (a). 6 (b). 6 (c). 6 (a). {2} "+" is Left-associative {2} "*" is Right-associative {2} "/" is Left-associative (b). {2} "/" has the highest precedence {2} "+" & "*" have the same precedence and have the middle precedence among the operators {2} "-" has the lowest precedence (c). {2} Correct associativity: ::= ^ {2} Correct precedence: "^" appears in correct position {2} Terminals should appear at the lowest line: ::= a | b | c {-1} For each minor mistake, like missing "-" in ::= - [2] Common causes for deduction in marks: - Wrong associativity: + few students has written ::= ^ which is left-associative and different from the specification of "^" - Wrong precedence: + few students has put ::= ^ at the first line, and forgotten the highest precedence of "^" - Minor mistake: + miss "-" in ::= - + forgotten to add ::= + wrong non-terminal names are used [3] 1 mark is deducted for every minor error ----------------------------------------------------------------------------------------------------------------------------------------------- Remarks for Problem 4: Special cases where points has to be taken off: 1. In consistency of location where fp points to. 2. The location where fp points to and the location where the control links points to is inconsistent. ----------------------------------------------------------------------------------------------------------------------------------------------- Remarks for question #5: [1] marks distribution over sub-parts are indicated in curly brackets {}: a. 3 b. 4 c. 4 d. 5 a. Val F = fn : int -> string --- ------ * minus 1 mark for every error in type. (e.g. something likes int -> char - minus 1 mark) ---- b. val F = fn : (int * int) list -> int list --- --- ---- -------- {1} {1} {1} {1} * no mark if the structure and type is wrong seriously. (e.g. something like int*int*int list -> int list) c. val F = fn : ('a -> 'b) -> 'a -> 'b -- -- -- -- {1} {1} {1} {1} * no mark if the structure is worng. (e.g. something like 'a * 'b * 'a -> 'b d. val F = fn : ('a -> 'b) * ('c -> 'a) * 'c list -> 'b list ---------- ---------- ------ ------ {1} {1} {1} {1} {1} - structure correct. (i.e. correct input and output type) [2] Common causes for deduction in marks: - wrong understanding of type in SML functions, such as: + string ---- SHOULD BE int -> string + val F = fn : 'a * 'b * 'c -> 'a list ---- SHOULD BE INTERPETED AS function F takes 3 parameters of type 'a, 'b, 'c resp. (note they are not the same type) and will return in type 'a list [3] - 1 mark if the use of the worng symbols. (e.g. integer instead of int). Deduct the marks once for each symbol. 0 mark if not writing the type of function in ML. (e.g. string instead of int -> string) ----------------------------------------------------------------------------------------------------------------------------------------------- Remarks for question #6: [1] marks distribution over sub-parts are indicated in curly brackets {}: a. 3 b. 6 c. 5 d. 3 e. 6 and 1 mark for the expression: exception WRONG_FORMAT; {1} exception WRONG_FORMAT; {1} fun odd_list [] = false {2} | odd_list (x::T) = not (odd_list T); {1} fun odd_item [] = [] {1} | odd_item [x] = [x] | odd_item (x::y::T) = if (y <> "+") {2} then raise WRONG_FORMAT {2} else x::(odd_item T); {1} fun strl2intl [] = [] | strl2intl (x::xs) = {2} (str2int x handle NOT_INT => 0) {2} ::(strl2intl xs); {1} fun add_int [] = 0 {2} | add_int (x::xs) = x + add_int xs {1} fun eval_iexpr L = if odd_list L {3} then add_int (strl2intl (odd_item L)) {2} else raise WRONG_FORMAT; [2] Common causes for deduction in marks: - syntax error such as: + == for equal --- SHOULD BE = + != for NOT EQUAL --- SHOULD BE <> + odd_list [x::T] --- SHOULD BE odd_list (x::T) + all operations about exceptions - common programming errors: + odd_list x::T --- SHOULD BE odd_list (x::T) + add_int strl2intl odd_item L --- SHOULD BE add_int (strl2intl (odd_item L)) + auxiliary functions are defined after their use + not exhausting all possible cases in function definition + type mismatch in different cases of a function e.g. add_int [] = [] [3] Marks are deducted ONLY ONCE for errors which occur more than once.