{"id":5444,"date":"2018-04-08T13:00:10","date_gmt":"2018-04-08T13:00:10","guid":{"rendered":"http:\/\/writeasync.net\/?p=5444"},"modified":"2018-04-08T01:36:48","modified_gmt":"2018-04-08T01:36:48","slug":"basic-complications-expressions","status":"publish","type":"post","link":"http:\/\/writeasync.net\/?p=5444","title":{"rendered":"BASIC complications: expressions"},"content":{"rendered":"

My GW-BASIC saga<\/a> continues. I’m on the third rewrite now of this “simple” translation app. I keep encountering problems that ultimately challenge core design decisions I made early on. Given the time scale and the fact that this is a toy project (and not, say, the Netscape browser<\/a>), starting over is actually saving me time. On each rewrite, I approach the problem with more clarity than before and, if nothing else, get much more quickly to the point where I throw it all away again. It is a real-ish version of Michael Feathers’ “disappearing code” experiment<\/a>.<\/p>\n

Having seen this problem from a few angles now, I have determined there are at least three “hard sub-problems” that must be cracked in order for a reasonable GW-BASIC to C# translator to emerge:<\/p>\n

    \n
  1. Parsing GW-BASIC statements<\/li>\n
  2. Parsing GW-BASIC expressions<\/li>\n
  3. Translation to C#<\/li>\n<\/ol>\n

    It seems obvious in retrospect — tautological<\/a>, almost! — but there is something to be said for experiential learning<\/a>. At this point it’s like I’m doing a very, very long code kata<\/a>.<\/p>\n

    Today I want to drill into sub-problem #2 above, GW-BASIC expression parsing. I did not originally distinguish this from plain old GW-BASIC statement parsing, but the most recent rewrite trigger brought it into focus. As a diligent TDD’er (Geepaw Hill<\/a> would be proud!), I had a good set of green tests and was about to implement the next feature — the ‘AND’ logical operator<\/a>. Try as I might, I could not get the new failing test to pass without breaking many other tests in wholly unexpected ways. While Sprache<\/a> had been a big help and massively increased my parsing productivity, the resultant parsers had become hopelessly complicated over time.<\/p>\n

    Looking back, there was an earlier sign that I was on the wrong path. Almost every new test I was adding ended up in the “IfThen” statement parsing fixture. But these were clearly expression parsing tests masquerading as IF\/THEN tests — if only I had listened to the tests<\/a> sooner.<\/p>\n

    With the benefit of hindsight, I am going to proceed by building just<\/em> an expression parsing library. Once I can show that parsing expressions works in isolation, I suspect that statement parsing will be much simpler. In essence, I can avert the eventual combinatorial explosion of the earlier tests and cover the two concerns separately (turning products into sums, as @jbrains would say<\/a>).<\/p>\n

    The ExpressionSample project on GitHub<\/a> shows the fruits of this labor. It is still a work in progress, but has support for the following:<\/p>\n