RESOLVE Error-Checking Utility
Advisor: Paolo Bucci
Participant: Brad Moore
Start Date: Autumn Quarter 02
Project Status: Completed
Index:
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:
Return to Europa
Brad Moore <mooreb@cis.ohio-state.edu>
Last modified: Mon Jan 27 18:37:12 EST 2003