Introducing SnowC

:date: 2026-07-24 10:18

"The reasonable man adapts himself to the world. The unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man." — George Bernard Shaw

If I were to play a reverse Turing Test video game where computer nerds impersonate a chatbot in a battle royale to the death — which is strangely still the way computer nerds are hired today — I would not imagine myself as an obvious natural champion. However Silicon Valley has made me feel like the one-eyed man in the land of the blind when it comes to good ideas for using computers to solve problems that should be solved.

In August of 2015 I had one of my best ideas which I wrote about in a blog post titled I’m Dreaming Of A White C. Although the topic of C programming can be complex, the quick summary of my insight is this simple dilemma.

Either...

Your C code contains fundamental redundancy.

Or...

You are styling your C code in such a way that you should exit the profession.

It is a big claim. From Kernighan to Ritchie, from Stallman to Torvalds, I'm accusing all C programmers of Doing It Wrong.

As years wore on, my pride of having had this insight turned to embarrassment that I had not solved it. In my original post I demonstrated a superficial algorithm for converting something reasonably structured to ordinary C and getting that to compile. For over ten years I wondered, what would it really take to do this properly? Now I know.

This summer I have been working on a new variant of C called SnowC. SnowC is short for "Semantic Non-Optional Whitespace C". (Or "Syntactically Normal Obligatory Whitespace C". Or "Structure Now Only Whitespace C". Or something like that. Or "SNO White C". Whatever.)

The basic premise is that SnowC requires you to style your code in a way that will not bring disgrace upon your family. By ensuring this, most of the inherent redundancy of C can be safely removed.

Perhaps the simplest way to describe the project is: there is no reason why the obligatory whitespace syntax of Python can not be applied to C.

SnowC is basically C with no obligatory (block) braces or semicolons. Instead it uses ordinary sane whitespace to achieve the same effects.

Is this a good idea? Yes it is. In 2020, I noticed one of the greatest C programmers of all time agreed with me.

I recently started
working in python, and I kind of like the indent scope bit -- I tend
to think the —

Because the basic coding style of C broadly inspired much of modern programming (Java, Perl, JavaScript, Go, Rust, Awk, etc.), it's worth reviewing how we got here.

The only programming course in my university education was Fortran. The year was 1990. Fortran90 was released in 1991. This means that the only formal university education about programming I ever had was in Fortran77, a language designed mostly in the early 1950s that envisioned source code being saved to physical paper punch cards. Making such a language work required careful and rigorous formatting alignments. And I can tell you first hand, wow, did that suck! It's easy to see why people designing languages in the late 1960s were keen to leave all that fuss behind them. Languages like B, Algol, Pascal, SQL, and of course C, were having none of that.

At that time new terminals meant source code didn't have to always be printed on paper to review it. New powerful editors made any printout simply a waste of paper. New and powerful tokenizers and parsers meant that "structure" could be more conceptual than physically literal. In this environment you can imagine how the designers of C went all in with empowering the programmer to be a code style artiste. The ethos was: you can write code however you want!

That sounds good, but there is a dark side to this. I once had a disturbing conversation with one of the brilliant grad students I worked with back at https://sysnet.ucsd.edu. We were talking about comments in code and he asserted simply that comments are bad. As a devout believer in Knuth inspired literate programming, this shocked me. What was most disturbing was that I could understand his point — which was that the code tells the truth, but comments might be telling the truth. Indeed if my job were to review other people's code for security concerns, I would strip comments before looking at it.

It turns out that this grim reality applies to any discretionary source code — including whitespace. Can whitespace really lie? Yes it can.

A beautiful example, can be found in "The C Programming Language" by C creators Dennis Ritchie and Brian Kernighan (aka K&R). Have a look at the code and commentary on page 51 (of this online version, or page 56 of my 2nd edition paperback, or page 52 of my 1st edition paperback).

The ambiguity is especially pernicious in situations like this:

    if (n > 0)
        for (i = 0; i < n; i++)
            if (s[i] > 0) {
                printf("...");
                return i;
            }
    else /* WRONG */
        printf("error -- n is negative\n");

The indentation shows unequivocally what you want, but the compiler
doesn't get the message, and associates the else with the inner if.
This kind of bug can be hard to find; it's a good idea to use braces
when there are nested ifs.

This kind of error is impossible in SnowC!

Here is a side by side comparison of the original C (left) and SnowC (right) where the conversion automatically corrects the error.

$ echo "=== $F";pr -w$(tput cols) -o1 -s'| ' -tm $D/$F <(./c2snowc -i4 $D/$F)
=== KR051.c
 if (n > 0)                               | if (n > 0)
     for (i = 0; i < n; i++)              |     for (i = 0; i < n; i++)
      if (s[i] > 0) {                     |         if (s[i] > 0)
          printf("...");                  |             printf("...")
          return i;                       |             return i
      }                                   |         else /* WRONG */
 else /* WRONG */                         |             printf("error -- n is negative\n")
     printf("error -- n is negative\n");  |

This example also coincidentally shows an especially evil problem for someone wanting to write something like SnowC (matching elses to ifs). And the commentary by K&R also coincidentally supports a conjecture I have that SnowC is closer to what the language designers were attempting than what they got. I will be writing separate posts on these topics and explaining how SnowC works in greater detail.

This project has had three major phases. I knew that for this kind of a system to be serious it must engage with the very messy world of extant C programming. Phase one has been to write a system that converts C code as found in the wild into SnowC. That program (demonstrated above) took about two months to write. Phase two was writing a program that converts SnowC back to compilable C. That took one day! Let that give you an idea of the sensibly structured nature of SnowC. Phase Three was to improve both programs sufficiently so that I could make the "round trip" by converting the c2snowc.c original C source code into SnowC, then convert that back to C, and then compile that into something that could repeat the cycle. That also took one day. This means that I have achieved the major milestone of being able to develop the SnowC code base in SnowC itself.

I'm sure there are many bugs and much development remains yet undone, but this is significant progress toward that dream I had in 2015.