milestone:
Try out each toolset on a Tiny example
The purpose of this milestone is to make sure that your group
functions well together, to get each toolset installed and working on
a small example, and to help you compare between toolsets and
languages. You must make these changes for each of
flex/bison/C, SableCC 2/Java, and if you do not wish to use either of
those, additionally whatever third toolset you are thinking of using
for your WIG project (e.g. SableCC 3, XText, PLY, flex/bison/C++,
etc.). In other words, every group must do the exercises for
flex+bison and SableCC 2, and some groups will elect to do them for a
third toolset/language combination as well.
You must do the following for each evaluator:
 Extend the Tiny expressions with a modulo
operator
% and
an abs(<exp>)
function.
 Extend the Tiny expressions with an exponentiation operator
**. Note that this operator is rightassociative,
i.e. 2**3**4 is to be parsed as 2**(3**4). Also note
that this operator has higher precedence than all other numeric
operators.
 Fix the pretty printer to output the minimal number of parentheses
required to preserve the semantics of the expression: not too few and
not too many. You should include support for the additional operators
from the previous steps.
 Introduce a unary minus
operator
<exp> as
syntactic sugar for the
expression 0<exp> . This
means that unary minus should be defined in the grammar, but not in
the abstract syntax trees, meaning there should be no changes to the
pretty printer or evaluator. This question is somewhat tricky in
SableCC. If using the version 2 syntax, you need to write a CSTtoAST
pass that builds an AST and in doing so strips out the unary minus.
If using the version 3 syntax, there is no way to create a '0' node.
You can either a) create a null node and then use a later pass that
replaces it with zero, or b) perform a post pass that fixes up any
unary minus nodes directly.
 The evaluator currently tries to determine the value of the input
expression. Fix it to:
 Handle division by constant zero properly. This means that an
error message should be printed for evaluating
<l_exp> / <r_exp> where
<r_exp> evaluates to
zero.
 Handle partial evaluation of expressions involving identifiers.
For instance,
a + 3 * 4 should
evaluate to a + 12 and no error
message should be printed.
 Perform basic algebra on identifiers. For instance,
0 * a should evaluate to 0 .
Include extra tests in the testcases file that demonstrate your
ability to handle good and bad input appropriately. Running make check will create a file called
result that will contain the
output. We will combine the testcases from all groups and use them to
test your improved Tiny expression evaluators.
Finally, based on your experiences, answer the following questions for
your milestone report:
 Which toolset you will use for the WIG project?
 What was frustrating about this milestone? Difficult? Time
consuming? Boring? Easy? Interesting? Fun? You can include
discussion of things such as using version control, group
coordination, and environment setup.
 What devious extension to the Tiny expressions should we ask
students for next year?
The original Tiny source code is here: tiny.
Use svn cp to create a branch groupX/tiny/ ,
check that in, and then start your modifications. The milestone
report should be checked in as groupX/reports/tiny.txt, ASCIIonly,
80 characters wide.
This milestone is due by midnight on Friday of Week 4. It will count
for 10% of your grade and take into account the work for this week,
the work for last week, and the initial preparatory work of sending in
your ssh keys and answering the interview questions. Marks will be
generously deducted for late submissions.
