From 4c61a5bce3d39fb96bbfac620debbceeaa9f9f5f Mon Sep 17 00:00:00 2001 From: Chris Date: Wed, 11 Mar 2015 16:03:58 -0400 Subject: [PATCH] added exercise --- exercises/_assignment7.mdwn | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+) diff --git a/exercises/_assignment7.mdwn b/exercises/_assignment7.mdwn index cd798ab0..d351b1b5 100644 --- a/exercises/_assignment7.mdwn +++ b/exercises/_assignment7.mdwn @@ -23,3 +23,28 @@ notes, prove that the evaluator does reduce expressions inside of does not perform reductions in those positions. + +3. In the previous homework, one of the techniques for controlling +evaluation order was wrapping expressions in a `let`: `let x = blah in +foo`, you could be sure that `blah` would be evaluated by the time the +interpreter considered `foo` (unless you did some fancy footwork with +thunks). That suggests the following way to try to arrive at eager +evaluation in our Haskell evaluator for CL: + + reduce4 t = case t of + I -> I + K -> K + S -> S + FA a b -> + let b' = reduce4 b in + let a' = reduce4 a in + let t' = FA a' b' in + if (is_redex t') then reduce4 (reduce_one_step t') + else t' + +Will this work? That is, will `reduce4 (FA (FA K I) skomega)` go into +an infinite loop? Run the code to find out, if you must, but write +down your guess (and your rationale) first. + + + -- 2.11.0