Project Description and Due Dates

Due Date	Task
Jan. 27	Form a team of five and submit the names of your five team members to me.
Feb. 10	Submit a whitepaper on the proposed language modeled after the Java whitepaper.
Mar. 8	Submit a tutorial patterned after the dot guide, which is a language for specifying directed graphs that you want drawn by a graph drawing algorithm.
Mar. 29	Submit a language reference manual patterned after the appendix in the dot guide or the C reference manual. The manual should include a formal syntactic specification of the language using extended BNF as well as additional information that one could not glean from the syntactic specification. For example, in C one would mention that main is a required function, or that the allowable operands to a "+" operator are one of the numeric types, short, int, long, float, double, unsigned, etc. It would also need to mention whether or not it is allowable to have different numeric types as operands (e.g., an int added to a float) and if it is allowable, then what kind of conversion gets performed. Finally it would need to mention would should happen in the case of arithmetic overflow and underflow (is an interrupt generated, does the program terminate, is some pre-defined value, such as NaN returned). The guide should be detailed enough that someone looking to implement your language could do so without having to constantly guess at what is allowed in the language. For example, if the C reference manual did not define the permissable operand types for the "+" operator, you would need to guess as to whether to support string concatenation with the "+" operator, or just numeric arithmetic. Similarly, if you just assume that everyone knows what is meant by numeric arithmetic, then an implementor will have to guess about what to do with different operand types.
Apr. 26, 28	Give a 20 minute presentation of the language to the class
Apr. 29	Hand in the final project report
May 2-6	Give a 30-minute working demo of the compiler to myself and the TAs

Team Roles

Once the teams are formed, each team will be asked to elect a project manager, \a system architect, a system integrator, a tester, and a language guru. Each of these positions carries specific team responsibilities:

• The project manager sets the project schedule, holds weekly meetings with the entire team, maintains a project log, and makes sure the project deliverables get done on time.
• The system architect defines the compiler architecture, modules, and interfaces.
• The system integrator defines the system development platform and tools, the integration environment, and a makefile or IDE project file to ensure the compiler components work together.
• The tester defines the test plan and test suites from the language reference manual. Each team member is expected to execute the test suites as the compiler is being developed to make sure the compiler meets the language specification.
• The language guru is responsible for overseeing the design of the language and managing and justifying subsequent changes to the language definition.

You will also need to divide up roles for writing the whitepaper, tutorial, and language specification, preparing and presenting the class presentation, and preparing and presenting the compiler demo. The work should be allocated as equally as possible and may be based on your strengths. For example, someone who writes eloquently may be responsible for more of the written material, while someone who speaks eloquently may do the classroom presentation, and someone who enjoys graphical design may prepare the presentor's slides.

Finally each team member will be responsible for writing at least 500 lines of code, excluding comments, in the final submission.

Should your team experience attrition during the semester, you will need to re-assign or share one or more team roles, and also pare back the features in your language. If your group suffers the loss of one member, my recommendation is that the role of tester be shared amongst the remaining four members and that the tester either move to the role vacated by the lost team member, or else that the remaining roles be reshuffled among team members. If your group suffers the loss of two or more team members, you can either reshuffle the roles yourselves or come to me for advice. The only role that I think can be shared is that of tester, so in a team that loses more than one member, at least one of the remaining members will have to assume two roles.

There are many benefits to this kind of project, including:

1. The opportunity to exercise your creativity in designing your own new language.
2. The opportunity to practice your technical writing and oral communication skills.
3. The opportunity to work in a team environment.
4. The opportunity to work on a large piece of software and to learn and experiment with new tools.

Format of the Final Project Report

Your final project report should have the following chapters:

1. Introduction (written by the team)
2. Language tutorial (written by the team)
3. Language reference manual (written by the team)
4. Project plan (written by the project manager)
5. Language evolution (written by the language guru)
6. Compiler architecture (written by the system architect)
7. Development environment (written by the system integrator)
8. Test plan and test suites (developed by the system tester)
9. Conclusions containing lessons learned (written by the team). I would like there to be individual team members' sections on lessons individually learned on each of the five tasks, and a collective section describing the lessons learned as a whole with working on a team and on a large piece of software.
10. Appendix containing the complete source listing of the compiler. Each file should contain the name of the team member who had the primary responsibility for writing the code contained in that file.

Your Grade

You will get individual grades for the role you play on the team and the components of the compiler that you individually write. Your evaluation for the role that you play on the team will include feedback provided by your fellow team members, my observations of your performance within the team framework throughout the semester, the chapter you wrote for the final project report that describes your part of the project, and your contributions to the language whitepaper, tutorial, reference manual, class presentation, and project demo.

You will get team grades for the language whitepaper, tutorial, reference manual, class presentation, and project demo.

Late Policy

It is the project manager's responsibility to ensure that due dates are met and a failure to do so will be reflected in the project manager's final individual project grade. Late submissions will also be reflected in the team's grade. There is no hard and fast amount by which your team's project will be penalized for late submissions. It will be based on the length of the delay, the number of delays, and any other factors that I may consider relevant.