Before writing code, first get a development environment setup (that’s the law. Except when you work in Smalltalk, but that’s a topic for a different article). I was already playing with parsers and had some test code lying around, so I used that to quickly get started. A simple build.sbt file:
One thing I don’t understand about sbt is that then I need to put my SBT eclipse plugin definition in
project/build.sbt, but when I include it above, it doesn’t work… So:
lets met generate an Eclipse project, and then I complete the skeleton with some borrowed code serve to act as the basis for getting started. The base class makes it simple to test individual parsers, which is exactly what we’re about to do.
The book starts with a definition of an atom, which is basically a chunk of uppercase characters. A first test is quickly created:
The implicit is a nice way to set the default parser to test during the test case. As parser combinators are functions, it is very easy to test them step by step - here we just exercise the to-be-created
At this point, I made one design decision - the introduction of an Atom case class to capture the parsed result. This will likely lead to a big hierarchy forming an AST, so accept the inevitable right away:
Not sure why I put the class hierarchy-to-be in an object, but, hey, we can always change it. The test still does not compile, because
atom is undefined. The book definition is quickly converted to a parser:
and the test is green. Time to git commit and celebrate!
The next installment will add basic S-Expression parsing.
this article discusses this version of the code