CMSC420: Introduction to Command Parsing, where nothing could possiblie go wrong.

This section is left in for completeness from previous semesters in case you want to 'roll your own' Command Parser. However, this semester you will be provided with the TA's 'adequate' command parser. It's not optimal(either in speed or coding style), but it is more than enough for what we will be doing.

Begin original commentary:

You are all blessed with a professor with a Ph.D. in fault tolerance. Because of this you will be expected to develop fault tolerant programs. This means bounds checking for input numbers and checking a number of possible error conditions for each command. It also means that your parser should never fail or crash because of a malformed command.

A really useful command interpreter would give useful error messages about commands, such as ``wrong number of arguments'', or ``invalid argument type'', or even better ``second argument was int, expected string''. For our purposes it will be sufficient to print a single error message regardless of the error:

        *****
        Error: Invalid Command.

Note the standard asterisks are printed. Do not echo the erroneous command.

Your parser must completely ignore blank lines. For all other lines which are not fully formed and correct commands you must print the above error.

As with other parts of the project, your command parser will be tested separately from the remaining requirements of the project. So if you can't get a fully error checking parser you will not be hurt on the other parts of the project. You may assume that for commands other than error checking all commands will be upper case and there will be no spaces within a command. There will be no blank lines and all commands will be valid.

A working parser cannot make any of those assumptions. Commands should be correctly interpreted regardless of case (ie. CREATE_DOT and creaTe_DOT should both be interpreted as the CREATE_DOT command). Blank lines should be completely ignored (in particular do not print extraneous ``*****''s). Whitespace in general should be ignored when parsing with one exception- any string (command name, dot name, or string arguement like the colors ``RED'' ``BLUE'', etc) cannot contain internal spaces. So a command like create_dot(foo bar, 5,6, BLUE) should be flagged as invalid.

Web Accessibility