I'm building a small interpreter for a language I created.

The grammar, lexer and syntax analyzer are already done.

What's confusing me is the interpreter part. I know interpreter pattern, but it seems too much verbose (more than it needs to be), I don't feel it's the right approach.

What are other alternatives I have to design my interpreter? (it's only the interpreter, not the parser).

The language that will be interpreted is a very small imperative language with if, while, attribution statement, input statement and output statement.

The language I'm using to create the interpreter is object-oriented, so I need an object-oriented approach.

I won't use any framework or similar, it's from scratch.

  • Did my question get a downvote?
    – Gabriel
    Commented Sep 14, 2016 at 16:24
  • 2
    You say you want an object-oriented interpreter but you reject using the standard pattern for object-oriented interpreters for no other reason than you feel a feeling that it is wrong. I'm not sure how to possibly answer this question, since it seems to be about you rejecting standard practices for no reason. My advice: write an interpreter in a way that makes you feel a feeling that it is right, get it working, and then review the code carefully to see if your feelings are a good guide for a well-engineered solution or not. Commented Sep 15, 2016 at 15:18
  • @EricLippert, I came here to see if someone could show me another useful and well known pattern to construct this kind of software. GoF's pattern isn't necessarily the best way to construct an OO interpreter. If you have experience in this area and think GoF's pattern is the best way to go, feel free to answer my question.
    – Gabriel
    Commented Sep 15, 2016 at 16:44
  • @EricLippert I edited my question to give some emphasis in the reason I think GoF's is not the right solution. I hope you can see it now.
    – Gabriel
    Commented Sep 15, 2016 at 16:47
  • Can you also explain why you are putting the cart before the horse? You have decided ahead of time that OO is the style to write an interpreter in, but OO is not a great style for the interpreter domain; as you note, interpreters written in an OO style tend to be pretty verbose, tend to put semantic logic into classes that ought to be representing syntax, and so on. The last interpreter I wrote was fully functional, not OO at all. Is your goal to end up with an interpreter, or to write in an OO style? Commented Sep 15, 2016 at 17:06

1 Answer 1


If you used a parser generator to implement parsing, usually it's possible to associate code actions to grammar rules. These code actions also receive the values bound to the lexical tokens and the values returned by other rules referenced.

Typically this is used to construct an abstract syntax tree (AST) for the code being parsed.

You then can descend along the AST and evaluate its nodes. This can also be done in an OO fashion, like for example using OO classes for the nodes, each with an "evaluate" method, or using a Visitor pattern, where again you can use OOP as it suits you.

Note that you can use a similar approach also if you are writing your own parser.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.