RU beehive logo ITEC dept promo banner
ITEC 380
2019fall
ibarland

grammars

due Nov.08 (Fri) in class, hardcopy and D2L. (I personally recommend completing at the very least #3, #5, and #7 by class on Wednesday, to help ensure you're on the right track.)
For non-code questions, submit a single pdf file named hw07.pdf, and code in a file hw07.rkt:

I suggest using a text-editor like Word (or LibreOffice or DrRacket or similar): The derivations are best written in a text-editor where you can copy/paste one line and replace a single non-terminal to create the next line. But for parse-trees, I recommend drawing them freehand.

Your hardcopy should include your answers, and your (presumably-hand-drawn) trees. Including images is optional for the pdf; I will use your hardcopy to grade the trees.

If you do want to incorporate your images (in the single pdf), you can of course do so via Word/LibreOffice/etc.; you may also do so via DrRacket's Insert » Insert Image…, and then printing to pdf.

Your name and the assignment-number must be in a comment at the start of the file, along with a link to this assignment page.

    grammars

  1. (2pts) “Check Your Understanding” Question 2.1 (syntax vs. semantics: p.53 in 4ed, or p.50 in 3ed) — give a short (1-2 sentences) answer in your own words.
  2. (2pts) “Check Your Understanding” Question 2.8 (re “ambiguous”: p.53 in 4ed, or p.51 in 3ed) — give a short (~1 sentence) answer in your own words.
  3. (4pts) Exercise 2.12, part b only (a parse tree for “a b a a”; pp.107–8 in 4ed, or pp.104–5 in 5ed, and is exercise 2.9 in 2ed).
    Ignore the “$$”; the book uses this to indicate end-of-input. I recommend drawing your tree freehand Make sure that each non-leaf node of your tree corresponds directly to a rule in the grammar (the node is a rule's left-hand-side, and its children are exactly the right-hand-side) — no skipping steps1.
  4. (4pts) Exercise 2.13, part b only (except make it a leftmost derivation of “foo(a, b)” rather than a rightmost; p.108 in 4ed, and p.105 in 3ed).

    I encourage you to actually put all the nonterminals in upper-case (or at least first-letter-upcased), just to make it easier to tell terminals from non-.

  5. Deriving lists, with a grammar:
    Suppose we had the following grammar rule for a javascript function, “<JsFunc>”:
    <JsFunc> → function <JsIdent>( <JsIdents> ) {
                 <JsBody>
                 }
    

    For the grammar rules, write them as in class: in basic BNF using “→” (and “ε”), but not using Extended BNF constructs like ? and * (nor equivalently, written as opt and ).

    1. (3pts) Define rule(s) for the nonterminal <JsBody>, which can be 0 or more statements.
      Presume that you already have rules for a nonterminal “<JsStmt>” (an individual statement; note that statements already include semicolons, so your rules shouldn't add any additional ones).
    2. (2pts) As we consider how to define <JsIdents>, a comma-separated list of identifiers, we note that the book has something similar: in the example of <id_list> (§2.3, pp.67–69), they present rules for a non-empty list of comma-separated identifiers (and, ending in a semicolon). Removing the semicolon will be trivial, but we do need to figure out how to adapt it to allow the possibility of zero identifiers.

      Working towards a solution, the programmer MC Carthy comes up with the following attempt for a nonterminal that generates repetitions of the letter “x”, separated by commas and ending in a semicolon (which we won't end with in our part (c), next):

           <XS>  →  ; | x; | x, <XS>
      
      This grammar can certainly generate “x, x, x;”.

      Prove that this grammar is not correct, by giving a derivation2 of some string which is not a valid comma-separated list-of-“x”s (ending in a semicolon).

    3. (3pts) Define rule(s) for the nonterminal <JsIdents> which correctly generates 0 or more comma-separated identifiers.
      Presume that you already have rules for a nonterminal “<JsIdent>” (a single identifier).
      You will need to include a second “helper” nonterminal.
    4. (3pts) Once you have your grammar, give a leftmost derivation of: function f( a, b ) { z = a*b; return a+z; }.
  6. (6pts) Generating a grammar

    Give a grammar for Java's boolean expressions. (That is: a grammar describing exactly what you are allowed to put inside the parentheses of a Java if () statement.)

    TODO Ian: first ask for a parse tree from the book's Example 2.4, for something like “2 + (x * -4)”. Students worked on linear-structures in previous examples, and continue that rather than seeing a tree-structure when asked for such a branching structure.

    For this problem, assume that you already have grammar rules for a Java numeric expression (“NumExpr”, probably similar but, for Java, more-complete-than the book's Example 2.4, p.46), for a Java identifier (“Id”), and that the only boolean operators you want to handle are &&,||,!,== and the numeric predicates >, >=, and ==. (You do not need to worry about making a grammar that enforces precedence / is unambiguous, although you are welcome to.) For this problem, you may use the Extended BNF constructs ? and * (or equivalently, written as opt and ).

    hints: Make sure you can derive expressions like “!!!!!!false” and “((((targetFound))))”, in addition to the expression below. You might want to ask yourself:
    • What is allowed to follow a “!”?
    • What is allowed on each side of “||”?
    For comparison, see that book Example 2.4, and what is allowed on either side of binary operators like “+”, and also what it allowed to follow the unary-negation “-”.

    Using your grammar, give a parse tree (not a derivation) for: a+2 > 5 || ((!false == x))
    In the tree, for children of NumExpr and Id, you can just use “” to skip from the non-terminal directly to its children, since you didn't write the exact rules for those nonterminals. I recommend drawing your tree freehand3.

  7. Trees

  8. (5pts) Write the function count-name, which takes in an anc-tree (as in lecture) and a string, and returns how many times that name occurs as a name in the anc-tree.
  9. (5pts) Write a function that takes in an anc-tree, an eye-color to change, and a new eye-color to replace it with. It returns a similar anc-tree where those eye-colors have been changed, but stopping if the new-eye-color is encountered. For example, you'll might replace all brown-eyed childs with a 'green except that when you reach a green-eyed person, you don't change any of their ancestors. Call your function change-eyes-to-until5.

1 I encourage you to notate, to the right of each step, the exact rule-number used for that step (numbering the grammar rules 1,2,3a,3b, etc.).      
2 The best answer is the shortest: if you have a simple example that uncovers the grammar's flaw, that is better than a long example doing so.      
3 You can turn in your printout + your drawing, or if you really want just one file to turn in, you can take a photo and then insert it into DrRacket.      
5 Well, more seriously: we’ll do an equivalent tree-traversal in the future, when working with parse-trees for a programming-language:
we’ll want to re-name all occurrences of a variable x, but if we come across a new variable-declaration named x, that’s making a new, different variable — so don’t change that x, nor any x in sub-trees of that declaration. We say that the newly-declared x is shadowing the original x being re-named.      
4 People sometimes wonder what possible use-case such a function could have. Well, sometimes you want to forge an ancestor-tree to make yourself appear to be irish, by having a version where all your 'brown-eyed ancestors are now listed as 'green. But once a particular branch encounters a real green-eyed ancestor, there's no need to extend the lie further. I mean, we have our standards, right?5      

logo for creative commons by-attribution license
This page licensed CC-BY 4.0 Ian Barland
Page last generated
Please mail any suggestions
(incl. typos, broken links)
to ibarlandradford.edu
Rendered by Racket.