4

I'm trying to implement simple imperative language in haskell.

Generally speaking my program is a list of statements (like arithmetic expression, if/then, block statement). My evaluator has simple state: stack of lexical scopes. Lexical scope is just map of variable name to value. I push lexical scope every time as control flow enters function or block and pop as control flow leaves function or block.

But I've encountered a problem while trying to implement evaluation of return statement. What I'm trying to do is to make a special case for return statement in main evaluating function(sources here):

evalStatements :: [Statement] -> Eval MaybeValue

-- nothing to evaluate
evalStatements [] = return Nothing

-- current statement is 'return expr', 
-- evaluate expr and skip the rest of statements
evalStatements (ret@(ReturnStatement _expr):_stmts) =
    leaveLexEnv -- leave current lexical scope
    evalStatement ret >>= return

-- this is last statement in function, eval it and leave lexical scope
evalStatements [stmt] = do
    res <- evalStatement stmt
    leaveLexEnv -- leave current lexical scope
    return res

evalStatements (st:stmts) =
    evalStatement st >> evalStatements stmts >>= return

evalStatement :: Statement -> MaybeValue
evalStatement (ExprStatemet expr) = ...
evalStatement (IfThenStatement expr stmt) = ...

But special case in evalStatements function looks ugly for me. And this approach doesn't work with BlockStatement, because return statement can be inside this block statement. Another problem is restoring stack of lexical scopes, when return statement is located inside multiple nested block statements.

I think I can solve this problem with storing some additional state in my evaluator, but this approach looks not very good. Something tells me that continuations can help me here. But I don't understand continuations very well yet.

What is best way to solve this problem? I need just an idea, general concept.

Thanks.

sergeyz
  • 1,308
  • 2
  • 14
  • 23
  • 2
    According to the monad laws, `(>>= return)` is always a no-op. You should remove those to simplify the code. And if it isn't a no-op, your `Monad` instance for `Eval` is broken. – Carl May 09 '14 at 15:04

1 Answers1

5

Continuations can work here, but they're way overkill. In fact, continuations are almost always overkill for solving any specific problem.

The simplest solution is to put the necessary logic into your Eval type. If you make Eval contain a constructor for "this computation returned early with this value", and then make your definitions of (>>) and (>>=) respect that, everything will work out automatically.

Carl
  • 26,500
  • 4
  • 65
  • 86
  • I use `StateT` transformer for my `Eval` type. It looks like `type Eval a = StateT Environment Identity a`. Should I implement `Eval` monad without monad transformers ? – sergeyz May 10 '14 at 15:45
  • 1
    @sergeyz This is actually not simple. There are a lot of options for how to implement it, and they all have different tradeoffs. Which one is best depends on tiny details that are hard to extract from short problem descriptions. My approach would be to back up and figure out exactly what operations `Eval` needs to support, make them into a DSL with an [operational](http://apfelmus.nfshost.com/articles/operational-monad.html) library, then figure out how to write an interpreter for that DSL. – Carl May 10 '14 at 16:52
  • thanks for the link to article, it's very useful for me. – sergeyz May 11 '14 at 14:51