K&R 2e

I don't have any progress to report on the development of the language - I'm currently trying to get structs working, and that's involved some pretty substantial breakage of the grammar. I had a grammar rule for assignments which was something like <variablename> = <expression>, which was sufficient for a while - I could evaluate functions and bind them to variables, I could have mathematical expressions, I could take the contents of variables, and assign them, things were rosy.

But then I tried "velocity.x = 3", and my structure didn't hold up anymore. I had already created the velocity struct, that part of the work was pretty much working (see my earlier posts about migrating to llvmlite in order to get aggregate types being generated). I even knew that the "x" member of the velocity structure was the zeroeth element, because I was keeping that information around.

I just ran into a stumbling block in how to represent a struct member as a "L-value", a thing that can be assigned to.

I looked at some online references for the C grammar, and found an ANSI C grammar which sent me down a rabbit hole of rewriting my expression productions. I looked at either pycparser or maybe pycparser (honestly, probably the first one) and I see a bunch of ways that my code can be cleaner, but I'm still not parsing struct assignment correctly.

I stumbled across a LALR tutorial which makes everything seem simple.

And, I guess, for simple languages, simple parsers are simple. But things get hairy quick.


C is, in a lot of ways, a simple language. I learned it in maybe a week, probably much less than that. I bought myself the K&R "white book" (pictured above) around Christmas of 1989. Hm, I'm not sure all of the chronology of this story makes sense, because I'm pretty sure I bought myself an IBM PS/2 286 in January of 1990, and I taught myself C on that 286 with the clackety keyboard and the VGA monitor and the 20 MB hard drive.

C is an easy language to dive into, and it's pretty easy to understand how things work. I still smile at the characterization of C as having the power of assembly language with the readability of assembly language. Looking at C and assembly today, it's easy for me to read either one of them, but the difference is the level of abstraction - there's more "idioms per line" in C than there is in assembly.

And then, there's C++, which I taught myself bits of in 1992 and 1993. Again, the structure of the language is there to afford more idioms per line than C. But I never found C++ quite as satisfying as C was, and over time, I managed to ship plenty of working C++ code, and pass several programming interviews, and I knew about the "diamond of death" multiple inheritance issues, and I knew about vtables, and it was fine, but I kept looking for something else.


On the flip side, when you look at the grammar of C, it's hard to call it "clean". There are simpler languages out there (LISP and PostScript come to mind, as well as a few proprietary languages that I've had to use professionally). In each of these environments, there's a balance between the complexity of the language tools (parser, compiler, interpreter, etc) and the productivity of the people using these tools. At one company I worked at, an engineer insisted that a scripting language was important to the project, but he couldn't convince management to allocate time for it, so a simple PostScript(ish) interpreter was coded up over a weekend, and that engineer was happy. Management was happy, because people were still on-schedule, and then junior engineers were given the task of creating a coding culture in this stack-based language.

Toward the end of that project, I was approached to see if I wanted to add "regular expressions" onto the language, which didn't make any sense to me. I'm pretty sure it didn't make any sense to the person asking me, either. Perhaps he meant infix operators, which would have been a substantial change to the language.


All of this to say, I still have fondness for C. I dug around in the house and found my 25 year old copy of K&R, and I'll be using that as a reference as I do some more hacking with the grammar of my language this weekend. Hopefully, I'll move closer to that sweet spot of clean language design balanced against clean language implementation.