You will design and implement an application-specific language for specifying tax forms. In particular, you will provide:
A language for specifying tax forms, and
A function that will "run" (interpret) a tax form in your language. Running a tax form prompts the user for the inputs to the tax form and outputs the amount of money that they owe or will get as a refund.
Both the language and the interpreter must support a specific subset of the 2006 US 1040 tax form (including schedules A and B). The two links below will allow you to download modified PDF versions of these tax forms. Your language should support all of the portions of these forms that are not blacked out:
You will do the project in two stages: a design stage, followed by an implementation stage. Each stage has a separate due date, as described above.
The goal of the project is to make sure each student can define, design, and implement an application-specific programming language. This is an individual project -- you may not work with your homework partner, or any other students, on this project (see the collaboration policy for more details).
For this phase, you will propose a language design for tax forms. You must submit both the proposed language and an example showing how to represent a non-trivial portion of the 2006 tax form 1040 in your language:
For the proposed language portion, submit the data definitions that you intend to use for tax forms. The design should be sufficient to capture the entire required portions of the 1040 form and the schedules A and B.
For the example, show how you will capture a non-trivial portion of the required portion of the 1040 form/schedules in your language. You do not need to specify the entire required portion of the form for this stage, but you should show enough to demonstrate how each part of your data definition is used in specifying a tax form. The example should be sufficient to convince us that you know what you are doing, and that the rest of the example will be easy to specify based on what you turned in.
You should NOT need to download any tax instructions to do this project. See the equations page for this information. If you need details that aren't on the forms, ask us and we will post them!
You do not need to be able to run the interpeter for your tax form language at the end of this stage. However you should evaluate your data definitions and examples to check for syntax errors! Creating the example tax forms should only invoke constructor functions for lists and the structures you have defined.
Submit an electronic file design.rkt containing your work for this phase.
Use the Pretty Big language for this assignment.
For this phase, you will provide a function
prepare-taxes that, when run, prompts the user for the
data needed for the entire non-blanked tax form (including two schedules) and reports on the amount owed or
overpaid. This function should process tax forms from your language
(tax forms are your programs).
We expect that you will revise or enhance your original language design as you try to implement the language. That's fine. Your project report will describe all changes you decided to make.
Provide a text file with answers to the following questions:
What must the TA do to run your tax form? Provide concrete
instructions (such as "execute (prepare-taxes form1040)"). The TAs won't
grade a project that they can't run.
What is the state of your implementation? Explain which features/aspects work and which don't. If you didn't get the schedules to work, for example, say so. This gives the TAs guidelines on how to test your system.
How have you changed your design since the version you submitted for the design deadline? Explain the changes and why you made them (e.g., "I found I couldn't do X because of problem Y with my earlier definition"). We're interested in seeing what doing the implementation taught you about the language design.
What, if anything, do you think could be cleaner in your design or implementation? If you are satisfied with your design, say so. If you think certain aspects should really be easier to use, easier to write, etc., explain those aspects and what you'd like to see different. No danger of losing points for honesty here (you'll only lose points for problems that we detect without reading your report) -- we just want to hear your assessment as we determine our own.
A file taxes.rkt containing your work for this phase.
A file report.txt containing your project report. Please submit this in plain text, rather than in Word format.
Submit these both via turnin, under the name project-final.
In general, the design phase counts for 25% of your project grade, the implementation phase (including final language design) for 70%, and your project report for 5%.
We will grade your language designs on a 4-grade scale (check+, check, check-, no credit). At this stage, we're looking to see whether you thought out the design phase well -- did you identify appropriate data, control, etc? Does your design adequately support the example you submitted?
There's no single right answer for this part, and while we will make suggestions on your designs, we won't give you a single right answer to follow when doing your implementation. Part of the exercise is for you to have to work with, and perhaps revise, your initial language design when it comes time to implement your tax package.
In the implementation phase, we will be looking at your final language design and its implementation. More specifically:
A passing (C) grade on the project requires a reasonable
language design that captures almost all of the required 1040 form
(but not necessarily the schedules) and a prepare-taxes function that
correctly processes the (smaller) portion of the language that you're
specifying.
A grade of B requires that you satisfy the requirements of a C grade for the entire required portion of the tax form, including the schedules. The final language design also has to be fairly good.
A grade of A requires that you satisfy the requirements for a B grade, and that you provide a cleaner, macro-based interface to your data definition for tax forms. You should also have a very good language design for an A.
We will not grade your user-interface based on its visual appearance. Simple text I/O is fine for this assignment. In contrast, adding features while your design isn't yet robust will cost you points.
We will grade your report for writing (complete sentences, spelling, punctuation, clarity, etc.) as well as technical content.
We will look for whether you followed good coding practices, such as uses of helper functions, in your prototypes.
We expect you to follow the Homework expectations (i.e., contracts and purposes are required) on this assignment, with the exceptions that:
read.
In general, adding a test case for a function that returns void is not required. However, you might want to do so in order to improve your test case coverage. Use your judgement. One of the most important reasons for the testing methodology is to help you debug your code. Don't just add testing at the end because we made you do it :-).
See instructions for how to enable testing in Pretty Big.
This is an individual project. Collaboration is not permitted on this assignment. The course staff are the only people you may approach for help with this project (but do come to us if you need help). You may not ask anyone outside of the course staff questions on any aspect of this project. This includes:
Violations of this policy follow the general course collaboration policy, and may result in an NR for the course.
Why this policy? Given the fairly open collaboration policy on homeworks, this assignment helps us assess how much each student understands of the course material. Since some students struggle in timed situations such as exams, the project gives you a more open-ended setting in which to demonstrate what you've understood of the course material.
Back to the Assignments page