RESOLVE Error-Checking Utility

Index:

Abstract
Calendar
Project Development
Findings and Contributions
Links and References
Return to Europa

Abstract:

RESOLVE/C++ is a instructional programming language that is more or less a modified subset of C++. Therefore, it can be compiled with the use of a generic C++ compiler. This means that all C++ syntax rules are enforced in RESOLVE/C++. The problem is that the C++ compiler does not enforce RESOLVE/C++ syntax rules. The goal of this project is to produce a utility that will enforce all RESOLVE/C++ syntax, as well as clarify some error messages the C++ compiler may give.

Due to the immediate need of such a tool, and the complexity of the RESOLVE/C++ language, I decided not to create a parser. Instead, the RECU breaks input into very basic tokens (i.e text, braces, whitespace) and only partially parses the code. Hence, I refer to it as a RESOLVE Error-Checking Utility and not a RESOLVE Parser.

Calendar:

Autumn Quarter 02 -- Started the project
Winter Break (02-03) -- Completed implementation
Spring Break 03 -- Recieved feedback from students

Project Development:

My lack of experience with straight C++ and familiarity with RESOLVE/C++ compelled me to implement the RECU in RESOLVE/C++. I spent a lot of Autumn quarter figuring out how to design my own template/class in RESOLVE/C++, and also designing the RECU.

During the first week of Winter Break, I changed my initial design substantially and even reimplented the RECU_Tokenizer. But, with the new design progress came rapidly.

Here's a current list of all the errors caught:
1) Missing parameter modes
2) Missing or Invalid return type in function headers
3) Missing ampersands in function/procedure headers
4) Missing object keyword
5) Mismatched braces
6) Using invalid C++ keywords
7) Missing {}'s around control stuctures
8) Using = and == in the wrong places

Findings and Contributions:

-- Finally received feedback during Spring quarter. I made a presentation to Tim Long's CIS 321 class, and posted to the CIS 321 course newsgroup. The students were then able to use the utility for their labs this quarter. I got positive feedback from the students in the class I was grading for. Other graders said they noticed a drop in simple RESOLVE/C++ related errors.

Even though my original project design is completed, there are some more features that could be implemented. Paolo brought up the idea of tracing non-standard types, and the problems of using standard operators such as '=', '<=', etc on template types. I think this could be implemented without changing the basic design of the RECU. It might take reorganizing some functions to send and recieve lookahead tokens, but the program currently does know when a variable is being declared.

One last note, I did notice something interesting about my implementation: it really does seem to resemble a recursive-descent parser. With that in mind, I wonder how hard it would be to come up with a RESOLVE/C++ CFG and then implement a parser with lex and yacc. However, that approach might have limitations with regards to the specificity of the error messages.

Links and References:

My Project Journal
RECU Tutorial

  Return to Europa