Writing an Interpreter in .NET (Part 3)

This is the third part in the series:

Writing an Interpreter in .NET (Part 1)
Writing an Interpreter in .NET (Part 2)

I have IExpression, ConstantExpression and VariableExpression implemented, using a BindingEnvironment to store a simple name-value dictionary for variables. I could reimplemented this environment or other parts if I need new functionality: using TDD, it’s relatively easy to add new features, preserving the previous ones.

In this post, I want to add commands (you can download the code from InterpreterStep03.zip)

The ICommand code:

namespace Interpreter
    public interface ICommand
        void Execute(BindingEnvironment environment);

The Execute  method receives the current state, now represented by a BindingEnvironment. The code was developed using TDD: I don’t need anything more to implement the tests.

First command to implement: SetCommand, set a variable using a name and expression:

First tests:

        public void CreateSetCommand()
            SetCommand command = new SetCommand("foo", new ConstantExpression(1));
            Assert.AreEqual("foo", command.Name);
            Assert.IsInstanceOfType(command.Expression, typeof(ConstantExpression));
        public void ExecuteSetCommand()
            BindingEnvironment environment = new BindingEnvironment();
            ICommand command = new SetCommand("one", new ConstantExpression(1));
            Assert.AreEqual(1, environment.GetValue("one"));

The implementation code:

    public class SetCommand : ICommand
        private string name;
        private IExpression expression;
        public SetCommand(string name, IExpression expression)
            this.name = name;
            this.expression = expression;
        public string Name { get { return this.name; } }
        public IExpression Expression { get { return this.expression; } }
        public void Execute(BindingEnvironment environment)
            environment.SetValue(this.name, this.expression.Evaluate(environment));

Note that the name of the variable and expression to evaluate are set at constructor.

Now, all the tests are in green:

Good code coverage:

Next step: add a lexer, that takes an string or file, and detects the tokens: words of our language to interpreter. Notably, the language specification could be in other project, and the implementation in the current one. But, for simplicity, I will add lexer, and after then, parser, in the same project.

Keep tuned!

Angel “Java” Lopez



Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s