Syntax analysis

In this mode, the ZurkParser tool reads in a GAME FILE and prints a syntactic analysis to STDOUT, including notes about any syntax errors that are encountered during the parse. This mechanism serves as a syntactic check on GAME FILEs, as well as a validation of the WDL parser itself. In this mode, ZurkParser reads a single GAME FILE from STDIN and writes the analysis to STDOUT. The analysis simply describes the content as it was parsed and makes note of syntactic errors; it does not attempt any semantic validation. Specifically, in this mode, ZurkParser does not attempt to ensure uniqueness of any NAMEs, ensure that a condstatement accesses only the correct number of arguments, test reference validity, etc. Instead, in this mode ZurkParser simply emits a note indicating syntactic recognition after each input statement. The output of the ZurkParser module will be used to grade Milestone 1, so it is critical that it be implemented precisely as follows. Note that if implemented correctly, ZurkParser in syntax analysis mode does not require any global state (beyond a single method) to be constructed or maintained.

Specific outputs are as follows. All outputs should occur only at the end of recognizing the corresponding WDL statement. (After the last terminal of that statement.) E.g., a Room declaration: output should only be issued after the closing brace of the Room WDL declaration is detected. Note that this will result in the contents of a declaration being printed before the declaration itself. All outputs MUST be followed by a single newline and MUST NOT be preceded by any whitespace.

References

Whenever a reference (RoomRef, ObjRef, etc.) is encountered, ZurkParser MUST print a statement of the form:

        X reference: refName

where X is the type of the reference (Room, Object, etc.) and refName denotes the NAME of that reference.

Declarations

Whenever a declaration (Room, Action, etc.) is encountered, ZurkParser MUST print a statement of the form:

        X declaration: declName

where X is the type of the declaration (Room, Object, etc.) and refName denotes the NAME of that declaration. Two special cases are VARIABLE and ACTION declarations which MUST be printed as:

        Variable declaration: vName(valsCount)
        Action declaration: aName(arity)

where vName and aName are the NAMEs of the VARIABLE and ACTION, respectively, valsCount is the number of values declared for the VARIABLE, and arity is the declared arity of the Action.

Descriptions

A WDL Description tag MUST be printed as:

        Description: "stringContents"

where stringContents denotes the text content of a string. See Strings, below, for details on printing strings.

Output producing statements

The print, error, and warn WDL statements MUST be output as:

        X: "stringContents"

where X is the name of the corresponding statement (print, etc.)

Strings

All output strings should be printed verbatim, with no extra or deleted whitespace. The double-quote (") and string concatenation (+) delimiters appearing in the GAME FILE MUST NOT be printed. The string MUST NOT be wrapped, but simply printed on a single line, as it is declared in the GAME FILE.

Conditionals

A condstatement MUST be output as follows:

        cond(nAlts)

where nAlts is the number of alternatives (including default, if it is present) in the condstatement.

Lvals

lvals MUST be output in one of the two following forms:

        Relative lval: $num.varName
        Absolute lval: absName.varName

The first form is for relative lvals - lvals specified by an argument number rather than an absolute object reference (e.g., $2.open). In this form, num stands for the provided argument index. The second form is for an absolute object reference (e.g., rose.color or Player.location). In this form, absName is the name of the absolute object reference (rose or Player). In both cases, varName is the VARIABLE name (open, color, location).

An example of a syntactic analysis for a relatively complex GAME FILE appears in Appendix B.

Any errors during the parse MUST be reported on STDERR. The format of the error description is up to the designer, but it MUST at least include the line number of the GAME FILE on which the error occurred and a description of the general nature of the error (e.g., Expected a TT_LBRACE but found a TT_NAME). Syntax errors MAY be treated as UNRECOVERABLE ERRORS (and ZurkParser terminated cleanly) or as a RECOVERABLE ERROR and the parse continued.