Writing a small parser / interpreter (Part 3: Semantic processing and simple WPF MVVM UI)

In the previous two steps we crafted a scanner and a parser for a subset of the LOGO programming language: Part 1: Scanner Part 2: Parser But, besides recognizing tokens and legal sentences, we also need to put semantic meaning into the LOGO programs.  Semantic recordings For this purpose we will use semantic records. A semantic record is introduced to remember context while parsing the LOGO sentences. Take a look at the following (parser) code-snippet: private ILogoCommand ParseLogoSentence() { ILogoCommand result = null; Token nextToken = scanner.NextToken(); sw... [More]

Writing a small parser / interpreter (Part 2: Parser)

In the previous step, we looked at how to write a lexical scanner for a small subset of the LOGO programming language. Our parser relies heavily on the fact that we're parsing a CFG language free from left-recursion (non-terminal not repeated as first symbol on lhs) and common left side prefixes (for any one rule, no productions share a common prefix). These properties enables us to write a special kind of parser, called a LL(1) parser. The first "L" means we're recognizing LOGO programs read left-to-right. The second "L" signifies that we're recognizing left-most parse-trees (parse-trees ... [More]

Writing a small parser / interpreter (Part 1: Scanner)

Perhaps some time in your career you've been asked to write a small "conversion tool", one which "shall perform a simple translation" of some text input and produce a text output. So, you grab the compiler or scripting tool of your choice and hack away at some regex parser thingy, right?! There is an alternative that at first glance seems daunting, but for most cases is pretty simple and definitely worthwhile. In the following three part sequel I will introduce the technique of writing a simple parser for a subset of the LOGO programming language in C#. LOGO(small) syntax LOGO is mostly kn... [More]

Faked Function Framework

Intro Perhaps you're doing embedded C programming and have been going through the motions of covering already written code by unit tests (as opposed to doing the development TDD style). Doing this, you've probably sometimes felt the pain of having to stub out an entire module, just to change the behavior of one single method, writing endless lines of repetitive empty method implementations. Or perhaps you find it hard to maintain your test code and share common stub traits? In that case, perhaps you need to look at Mike Long's faked-function-framework (FFF) as suggested by James Grenning at ... [More]