CST 8152 - Assignment 8 (Bonus)

Live demo required before August 12, 1997

The due date for the bonus assignment cannot be extended. I am away August 12-15.

Last Update: Sunday September 27, 1998 01:06

Purpose

This assignment allows you to demonstrate your mastery of your interpreter project.

Instructions

Add the IF/THEN/ELSE/ENDIF control flow statement to your interpreter using the following grammar production:

<if_statement> -->
   "if" <expression> "then" <statement>* ( "else" <statement>* )? "endif"

IF statements nest, with the optional ELSE clause belonging to the most recent IF. The interpreter must keep track of the nesting level.

Notes

Does the "endif" require a semicolon after it?

Should semicolons terminate statements, or separate them? In the following table, semicolons terminate statements in the left example, and they separate statements in the right example:

Terminator	Separator
if x > 0 then y = 0 ; z = 2 ; else y = 1 ; endif	if x > 0 then y = 0 ; z = 2 else y = 1 endif

If semicolons terminate statements, as they do in C, every statement must end with one. If semicolons only separate statements, only when you have two or more statements do you need them. Which method will your interpreter use? You might want to read Brian Kernighan's commentary on the subject in relation to Pascal. (Pascal uses semicolons as statement separators):

One generally accepted experimental result in programmer psychology is that semicolon as separator is about ten times more prone to error than semicolon as terminator.

You may need to enhance your panic() function so that it stops at control flow keywords as well as semicolons. Consider the following example:

if x < 0 then
   = 2 + 2    /* syntax error at start of this line */
else
   y = 1 ;
   z = 2 ;
endif

A panic() function that looked only for semicolons would skip forward into the middle of the ELSE clause of the IF statement, possibly causing further syntax errors, instead of stopping before the ELSE.

Parsing the IF/THEN/ELSE/ENDIF statement

Here are two ways (among many) of implementing the above production in your parser.

Method 1: Stupid IF

This method is used by the Unix "C Shell"-style command interpreters:

If the <expression> evaluates TRUE, do nothing special; continue parsing and executing normally. When the next ELSE is encountered, the parser starts calling the scanner and skipping all tokens until a matching ENDIF is found. After the ENDIF, execution continues normally.
If the <expression> evaluates FALSE, the parser starts calling the scanner and skipping all tokens until a matching ELSE or ENDIF is found. After the ELSE or ENDIF, execution continues normally.

The "stupid if" format doesn't detect syntax errors in the part of the input that is skipped over, since that part of the input isn't actually parsed according to the grammar. This means code such as the following "works":

if 0 then
   this junk * ) "xxz" ( is ignored + + + until the parser -/-** sees an
else
   print "This must be correct.\n" ;
endif

Method 2: Fancy IF

A method similar to this is used by the Unix "Bourne Shell"-style command interpreters:

If the <expression> evaluates TRUE, do nothing special; continue parsing and executing normally. When the next ELSE is encountered, the parser sets a flag that tells it to disable all semantic actions until the matching ENDIF is found. The parser parses each input statement, but does not execute it as long as the flag is set. After the natching ENDIF, the flag is turned off and execution continues normally.
If the <expresison> evaluates FALSE, the parser sets a flag that tells it to disable all semantic actions until the matching ELSE or ENDIF is found. The parser parses each input statement, but does not execute it as long as the flag is set. After the ELSE or ENDIF, the flag is turned off and execution continues normally.

The "fancy if" format requires that all input be syntactically correct, even input that is not executed.

This table shows the difference in the two Unix command interpreters' treatment of the input skipped over during control flow handling:

Unix Bourne Shell
detects syntax errors
in FALSE clause Unix C Shell
ignores syntax errors
in FALSE clause
if false; then
   ) foo
syntax error: `)' unexpected
Exit 2
if( 0 ) then
   ) foo
endif

Unix Bourne Shell detects syntax errors in FALSE clause	Unix C Shell ignores syntax errors in FALSE clause
if false; then ) foo syntax error: `)' unexpected Exit 2	if( 0 ) then ) foo endif

Deliverables for this assignment

Arrange a time to show me a demonstration of your interpreter. I will hand you a test file to run.

I am attending a professional development seminar in Kingston August 12-15 and will not be in town to see late assignment demos during this time, nor can I see demos while I am proctoring exams.

Ian D. Allen CST 8152 Home Page