What functions should we write for the design deadline?
None whatsoever. All you need to turn in for the design deadline is your set of data definitions and a representative portion of the form as captured in your definitions. For example, we were able to write examples of slideshow talks before we wrote the interpreter. Something akin to a sample talk program is what we're expecting with your design.
How do we handle references to page numbers in the tax instructions?
Ignore them. We'll give you formulas that depend only on the data in the tax form for each of those cases.
How do we handle references to blacked-out lines numbers?
Assume they contain zero.
What do we do with the name/SSN info when we print out the result of the form?
You can ignore them if you want. We left them in as a means of exercising your design, not your implementation.
What will the tax form interpreter do?
The tax form interpreter will prompt a user for all of the data needed to complete the tax form and calculate the taxes owed. Your tax form language should contain the info that the interpreter will need to request data and perform the calculation.
Should the user enter data from lines that copy info from one line of the form to another?
No. Your program should handle this automatically. Since the point of a tax program is to save the user from unnecessary work, your interpreter should only query the user when needed data isn't already available.
Do we need to worry about validating user input, e.g., that a value entered for a dollar amount is in fact a number?
No. Input validation is a crucial part of any complete application, but a systematic approach to this problem and error handling in general is beyond the scope of this course.