| Overview |
At some point in your schooling, you may have encountered the concept of diagramming sentences. A diagram of a sentence is a tree-like drawing representing the grammatical structure of the sentence, including parts such as the subject, verb, and object.
Here is an extended BNF grammar for some simple English sentences that we will use for the purposes of diagramming.
<sentence> --> <subject> <verb_phrase> <object>
<subject> --> <noun_phrase>
<verb_phrase> --> <verb> | <verb> <adv>
<object> --> <noun_phrase>
<verb> --> lifted | saw | found
<adv> --> quickly | carefully | brilliantly
<noun_phrase> --> [<adj_phrase>] <noun> [<prep_phrase>]
<noun> --> cow | Alice | book
<adj_phrase> --> <adj> | <adj> <adj_phrase>
<adj> --> green | lean | mean
<prep_phrase> --> <prep> <noun_phrase>
<prep> --> of | at | with
This grammar can generate an infinite number of sentences. One sample is:
mean cow saw carefully green Alice with book
(For simplicity, we ignore articles, punctuation, and capitalizing the first word of a sentence.)
The language for implementation is Pascal. Structured design using procedures and functions should be used. If your Pascal compiler includes object-oriented features you are not to use them. You will also gain more experience using BNF. Decide what the basic operations are that you need to implement, how those will be written as functions/procedures, and then how they can be used to build higher level functions/procedures, etc. An easy way to organize your solution is to construct one (parameterless) procedure for each nonterminal in the grammar. See Sebesta pp123-125 for details on recursive descent parsing. For example, the following procedure parses the non-terminal <adj>:
procedure adj;
{ The global variable "next_token" holds the next
token in the input stream. See Sebesta p.124 for details }
begin
write ('(');
if ((next_token = 'green') or
(next_token = 'lean' ) or
(next_token = 'mean' )) then
begin
lexical; { A function you write to advance to
the next token }
write (')')
end
else
error ('Input is not a sentence'); { A function you write
to handle errors }
end;
| Input Format |
Your program should read "candidate sentences", one per line, from its standard input (in the sense that this exists in Pascal). For each line of input, your program should attempt to interpret the line's contents (a whitespace-separated list of words) as a sentence. You will need to read each entire line in as a string. This string will have to be split into tokens by a lexical analyzer, which will then feed them to your parsing routine.
|
Output Format |
The output of your program should be produced on standard output (in the Pascal sense of the term). Your program should produce a "diagrammed" version of the input string, which means a sentence in properly parenthesized form. "Properly parenthesized" means that each nonterminal appearing in the input string now has parentheses around it (omitting all redundant parentheses). For instance, the input string:
"Alice found mean green book"
would be parenthesized as
(("Alice") ("found") (("mean" "green") "book"))
A more complicated example is
"mean cow saw carefully green Alice with book"
which returns
((("mean") "cow") ("saw" "carefully") (("green") "Alice" ("with" ("book"))))
In addition, there are two distinct error conditions that your program must recognize. First, if given a string does not consist of valid tokens, then respond with this message:
"Input has invalid tokens."
Second, if the parameter is a string consisting of valid tokens but it is not a legitimate sentence according to the grammar, then respond with the message:
"Input is not a sentence."
You may use write or writeln statements
in your parsing routines to generate the properly parenthesized
output. Your implementation is to be organized in a single file. The
comments at the beginning of the file
should identify the assignment and should give your name. Every Pascal
procedure/function should be preceded by comments explaining its
purpose, calling sequence, and implementation.
Be sure to follow the Program Submission Guidelines in preparing your report to turn in. In accordance with these guidelines, you will need to develop a set of test cases for your program that tests both positive and negative cases. In gathering information for your report, you may find it useful to place all of these test cases in a single input file that you can feed to your program through I/O redirection. You can then capture the results of your tests while running under a command prompt (Windows or UNIX) for inclusion in your program report.