Over the course of several homeworks,
we'll implement a “tower” of languages (P0, P1, …, P6)
each language incorporating more features than the previous.
P0 is provided for you.
(15pts) Implement P1 in both racket, and Java.
P1 is just like P0, but with two additional
types of expressions:
Expr ::= … | WhenPosExpr
WhenPosExpr ::= whenP Expr then Expr otherwise Expr !
BinOp ::= … | %%%
|
Update
parse,
toString (a.k.a. expr->string),
and eval
appropriately,
for both the racket and Java implementations.
Be sure to write test cases first.
The only method which cares what these new expressions mean
(their semantics)
is
eval:
-
For the expression (:x %%% y:),
eval should evaluate to1
x mod y,
where the result is always between 0 (inclusive) and y (exclusive);
in particular, the result should never be positive if y<0.
Notice that this is slightly different behavior than
either Java's built-in %
(which behaves differently on negative numbers),
and from Racket's built-in modulo (which only accepts integers).
In both racket and Java, you can calculate this as
y*(x/y-floor(x/y)).
Note that you are provided sufficient test cases for modExprs,
in the comments of the P0 test-case files.
For whenP Expr0 then Expr1 otherwise
Expr2!,
your eval should first evaluate just Expr0;
if that value is positive, then evaluate Expr1
and return its value;
otherwise evaluates Expr2 and return that value.
(Note how you are implementing short-circuit semantics for WhenPosExpr!)
You must make your own test cases for WhenPosExprs;
include at least two as-simple-as-possible tests, and two tests with more deeply nested
Exprs.
I suggest includine one where the
WhenPosExpr is not the top-level comment
(e.g., a +++ expression which contains a whenP
as one of its operands).
Complete two versions of P1: both racket, and java.
(For P2 and beyond, you can choose which implementation to continue.)
-
(25pts) Implement P2 in either racket or Java (your choice).
P2 adds identifiers to P1:
Expr ::= … | Id | LetExpr
LetExpr ::= fornow Id be Expr in Expr stopit // Subject to votes in class, for exact syntax.2
|
where Id can be
any series of letters and digits which isn't interpretable as a number3.
(Assume for now that any nested let
expressions
use different Ids.
We'll handle shadowing in P3, later.)
Update your three methods
parse,
toString (a.k.a. expr->string),
eval.
We now need to define the semantics of
fornow Id be E0 in E1 stopit:
-
Evaluate E0;
let's call the result v0.
-
Then,
substitute
v0
for
all occurrences
of
Id
inside
the tree E1;
name the result of the substitution
E′.
(Note: you must do substitution in the parse tree;
no credit given for string-substitution
5.)
-
Evaluate E′,
and return that result.
Observe that when evaluating a (legal) P2 program,
eval will never actually encounter an Id --
that Id will have been substituted out before
we ever recur down to it.
In order to make a substitution in an Expr
parse-tree,
write a helper function that does only substituting
(and does not do any evaluating in any way).
This task
is similar to taking an Ancestor-tree,
and replacing every blue-eyed Child with a brown-eyed one.
(The only difference
is that an AncTree had only two cond-branches,
while Expr has around seven,
though the code for most of those are very similar).
For example:
fornow x be 5 in (:x +++ 3:) stopit ⇒ (:5 +++ 3:) ⇒ 86.
Be sure to write test cases for your substitution function before
you write its code;
include several trivial and easy tests,
along with a couple of more complicated nestings
and one deeply nested expression.
You can choose implement P2 in either in Racket, or in Java.
1
Because we don't need to check for bad inputs,
it's fine to have your interpreter crash if y=0.
If you prefer to "control" crash — creating a meaningful error message
and calling error or throw yourself —
you are also welcome to do that.
↩
2
In class, we will choose one of the following or (most likely) a variant, as a class:
| ML-like: | let x = 2+3 in x*9 end; |
| lisp-like: | (let {[x (+ 2 3)]} (* x 9)) |
| lisp-like, simplified: | (let x (+ 2 3) (* x 9)) |
| C#-like: | using (var x = 2+3) { return x*9; } |
| javascript-like: | var x = 2+3; return x*9; |
| Java-like: | { int x = 2+3; return x*9; } |
| Haskell-like: | * x 9 \n where x = + 2 3 \n |
Another option for the assignment-character is “:=” (Ada,Pascal),
or “←” (indicating which way the data flows),
or even something like “Expr → Id { … }”
(which might make CS1 students happier — the processing happens left-to-right, just like we
read the statement).
Or, if we want to include emoji keywords,
good candidates are the entries on this page
which have the left-most column “native” filled in.
Note that you can (and should) test and write a “substitute” function w/o
worrying about the exact syntax of a LetExpr.
Substituing one thing in a tree for another is its own independent task,
de-coupled from eval'ing a local-binding statement.
↩3
Note that our different implementations are now varying by
more than just precision of arithmetic:
in a Java implementation, NaN is a Num,
and in a racket implementation it's an Id.
We won't use any test cases involving such subtle differences.
However, note how our choices in designing a new language
are being influenced by the language we're trying to easily
implement it in!
This stems from the fact that a primary design constraint on P is that
implementing an intepreter for P doesn't get bogged down in minutae when using
either Java or Racket.
↩
5
For example: what if a P2 programmer uses a variable
named “mod”
or “let”
or “fun”
[which we might make into a keyword in the future]?
While it's not advisable for somebody to do this,
and perhaps our parse should disallow this,
our eval shouldn't
give wacky results in this situation.
↩
4
All our real code should work on the parse tree itself.
String-substitution (like C pre-processor macros)
can't be generalized to handle shadowed variables (scope)
for P3,
and is in general
fraught with error5.
A local-variable construct which requires
globally-unique names isn't very impressive!
↩
6
The notation
“fornow x be 5 in (:x +++ 3:) stopit
⇒ 5 +++ 3 ⇒ 8”
is shorthand for
eval(parse("fornow x be 5 in (:x +++ 3:) stopit"))
= eval(parse("(:5 +++ 3:)"))
= eval(parse("8"))
|
Observe how we definitely don't write
“"fornow x be 5 in (:x +++ 3:) stopit" = "(:5 +++ 3:)" = 8”
since the two strings are not .equals(·) to each other,
and strings are never ints.
More specifically:
we distinguish between “⇒”
(“code evaluates to”)
and
“=” (“equals”,
just as “=” has meant since kindergarten).
↩
radford.edu