Here I’m going to try my hand at creating the start of an interpreter. This obviously follows on from the previous posts in this series.

If you’ve followed this series up to this point, you now have a lexing and parsing engine that, while not doing much, is passing its tests. What we don’t have is a way to really say that our language works because there’s no runtime. That’s what I’ll start to address in this post.

We left off with a parser test we wanted to execute (in parser_spec.rb) and a grammar file to generate a parser (in grammar.y). The actions specified in the grammar file, and thus what will be tested in the spec file, are nodes. So getting those nodes in place will be the focus of this post.

Following on from the second post in this series, a lexer has now been created that can tokenize some input for a hypothetical language. Given what was accomplished, theoretically I can use my language to create the most minimal sort of class definition. I’d really love to know if I’m completely on the wrong track here. So I’d like to get started on the parser at this point rather than fleshing out the language more.

Following on from the first post in this series, I did a development spike that proved to myself I had some clue as to what I was doing. So now I want to get into actually building a language from soup to nuts: meaning I want an interpreted language that executes via a runtime. Granted, this will be a very simple language (and not very unique). It will also be a very simple runtime. Let’s see what happens, shall we?

In previous posts I talked about how one of my goals was to come up with an alternative to Gherkin. This is not in the “just to see if I can” category but rather because I believe it could be useful to roll your own Gherkin-like language. This post, however, will be in the “just to see if I can” category. Here I want to take what I learned about lexing and parsing and apply that to creating a simple programming language. Fair warning: I have no idea how this is going to turn out.