BUILDING WITH BLOCKS;
                        OR WHY GOTO MIGHT NOT BE SO BAD
                         Collin McKinley - 2026-09-03

So this is going to be a bit of a departure from the normal type of essays I
tend to upload here.  This is more of a musing than something like a well
thought out and researched paper.  More or less this is a cool idea I had which
I want to share with the world and get some feedback.  So without further
adieu, here is quite possibly the most controversial statement I've ever made
in programming languages, I am starting to think "goto" might actually be a
good thing.


INTRODUCTION AND MOTIVATION
===========================

Two years ago, I took the class Software Development with Matthias Felleisen.
The biggest thing I took away from that class is that code should be _read_
more than it is written.  And at that, code should be _easy_ to read, not just
_possible_ to read.  What this means is making careful consideration of what a
problem is and how it can be solved.  Usually splitting complex tasks into
smaller, composable pieces with human readable names.  Lets say you have a
function which does multiple complex tasks.  In the interest of making it more
readable, you should typically isolate each task and make a so-called "helper"
function which only does that sole task.  Once this is complete, the helper
functions should be composed together to create the complicated task.  The
ultimate take-away is that the average function should be about 6 lines of
code.  If done correctly, a programmer should be able to get the idea of the
function by only looking at a single screen of text, as at some point, the
helper functions will need no investigation thanks to their human readable
names.

Another thing I've been doing lately is working as a teaching assistant for a
class on Computer Systems.  In this class, students are expected to write x86
assembly and C to solve various systems-level problems.  This class is
typically the first (and likely last) time students will see assembly or use
it.  One thing that has always amazed me though when grading for this class is
that the assembly code written by students tends to be orders of magnitude more
easy to read than the C code they will submit later in the class.  While
initially I had chalked it up to the assembly problems being easier (which
admittedly they are), I have come to find that assembly might be hiding a
really helpful structure which almost all programming languages do not have.  A
structure which allows you to effectively document _any_ complex task in a very
similar way to creating helper functions, all without the actual action of
creating those functions, or even thinking about creating those functions.

The structure that assembly has which no other language has is the label/goto
structure.  I have no other way to describe it.  In most modern programming
languages, there are a multitude of "control-flow structures".  These are
statements or otherwise which "move" us to another part of the code.  Take for
example this C statement which decreases the value of x until it hits zero,
then once finished prints the message that "X is zero!".

    while (x > 0) {
      x = x - 1;
    }

    printf("X is zero!\n");

The while loop runs the code contained in the block (enclosed by {}) until the
condition is evaluated to false, after that point, it will skip the code in the
block and run the next line.  Now consider the following code written in a
assembly-like language:

    zero_check:
      compare x, 0
      if-equal-goto print-x-is-zero
      otherwise-goto decrement-x

    decrement-x:
      x = x - 1
      goto zero_check

    print-x-is-zero:
      print "X is zero!"

In assembly, text which is followed by a ":" is known as a "label", and it
marks a position in our code which we can "jump" to, or start executing code
at.  While this example is in a totally fictitious assembly language, it is not
unlike many modern assembly languages currently in use.  The interesting thing
here when compared to C is tasks are named.  In our original C code, the task
of checking if x is zero is still performed, however it requires the programmer
to understand the code "while (x > 0) { ... }" to understand what the task is
doing.  While this is not exactly difficult to do (and most programmers should
hopefully be familiar with a while loop from any number of languages), it still
provides a barrier to communication.  In assembly, there is no abstraction over
control flow, therefore all individual tasks need to be given explicit names so
we can jump to them when need arises.

The reason that it felt easier to read student written assembly rather than
student written C was very much a result of this explicit naming.  As tasks got
more complex, intentions would typically get lost in the sea of nested while
and for loops.  At this point, it was no longer enough to look at the code and
get a rough idea of what the core idea was, it was now necessary to fully read
and interrogate the code, effectively simulating the runtime of it in your
head.  While some of this would probably be mitigated by using more helper
functions (and trust me, it totally would go a long way for some students'
code), there will always be cases in C where being dropped in a random line of
code will require some reading of context (sometimes hundreds of lines of
context) to figure out exactly what that line is supposed to be doing.


THE PROGRAMMING LANGUAGE ITSELF
===============================

There is no language yet.  I am still trying to figure out how best to
implement or realize this project.  However at the moment I do have it working
as a macro within Racket and can already see its benefits.  It doesn't have a
name at the moment, I tend to call it "Elehtra", which is the name I use for
any of my unnamed programming languages (the Old English word for the plant
lupine, pronounced like "electra").  At the moment it has the following syntax:

    (define/elh (<function-name> <function-args> ...)
      ((<local-variable> <initial-value>) ...)

      [<label>
        <code> ...
        <control-flow-statement>]

      ...)

Where "control-flow-statement" is one of the following:

    (next <label>)
    (if <condition> <if-true-label> <if-false-label>)
    (return <value>)

The idea is effectively to subdivide the function into a series of "basic
blocks".  These are a sequence of code which has a few interesting properties.
A basic block starts with a label (somewhere we can pick up execution from
elsewhere in the code) and ends with a control-flow-statement (which directs us
to somewhere else in the code).  Effectively we can only enter a basic block
from the top, and must always leave from the bottom.

The following is a basic example implementing multiplication using the method
of repeated addition:

    (define/elh (mult a b)
      ((result 0))

      [are-we-finished?
        (if (zero? b) final-result iterative-step)]

      [iterative-step
        (set! b (- b 1))
        (set! result (+ result a))
        (next are-we-finished?)]

      [final-result
        (return result)])

The equivalent function in C would look as follows:

    int mult(int a, int b) {
      int result = 0;

      while (b != 0) {
        total = total + a;
        b = b - 1;
      }

      return result;
    }

Keep these examples in mind for the following section.

The source code for Elehtre can be downloaded from:
https://mckinley.net/~collin/pub/elh.rkt


INTERESTING PROPERTIES OF BASIC BLOCKS
======================================

Immediately, the most interesting property of the basic block structure is how
much less code needs to be read in order to understand the flow of execution
through a function.  A basic block is effectively the realization of a flow
chart in code form.  In order to understand a function at a high level, all you
really need is the label, which gives you a high-level idea of what the block
is doing, and the control flow statement, which tells you where execution is
going.  Intuitively, we can make a graph such as the following only from these
two pieces of information for the function above:

    are-we-finished? ----> final-result
          |  ^
          V  |
     iterative-step

While we don't exactly get the nuance of how the code is functioning, we do get
the big picture idea of how the function runs in a similar way to what we would
get from composing simple functions together to solve a complex task.  In a
similar way, we also reach a point where we can intuitively understand what a
given basic block is doing without needing to interrogate it.  If I were
personally given the graph above, the first place I would look is
"iterative-step", since that seems to be the place where the work happens.  I
would likely completely ignore "final-result" unless I really needed to check
it since intuitively, I can understand that it likely just returns the final
result of the multiplication and/or cleans up stuff we no longer need.  In a
similar way to knowing what the function "add5(x)" must be doing, we can make a
lot of generalizations about the code very easily when we know a basic idea of
what its doing, and all the places we could be going next.

Another very interesting property of basic blocks is the fact that the body of
the block is totally uninteresting.  The only real parts we need to care about
are the transitions and where they are going.  This has major implications for
debugging a program.  Recall the multiplication function I presented above.  I
deliberately wrote a subtle, but crippling bug into it, it always assumes "b"
is positive.  If "b" is negative, the function will run forever (assuming the
computer can count to -infinity).  In a traditional language like C, to
diagnose this issue, one would typically use a debugger and run each statement
one after another to follow the flow of information and find the problem.
While this approach works perfectly fine, you end up wading through a lot of
useless "tautologies" which will _never_ be the problem.  For example, while
the code "b = b - 1" is a symptom of the problem, the actual problem is the
statement "b != 0".  Because of this need, most C debuggers have a notion of
"breakpoints", or manually selected places in the code of interest, which upon
reaching, the debugger stops and dumps information.  This is given to us
completely for free with basic blocks, as the transitions are de facto
breakpoints.

With basic blocks, this same debugging can be done simply by looking at
transitions and the value of variables at that transition.  A bad execution
could look like:

    are-we-finished?
      a = 1
      b = -1
      result = 0

    iterative-step
      a = 1
      b = -2
      result = 1

    are-we-finished?
      a = 1
      b = -2
      result = 1

    iterative-step
      a = 1
      b = -3
      result = 2

    ...

When debugging in C, we are constrained to the "little picture", with each
individual statement being equally important for the flow of the program.  With
basic blocks, the properties which we established earlier basically ensure that
anything inside the block is totally mundane, and the interesting part is the
transitions.  By just looking at these transitions, like shown above, we can
easily identify that we will never pass the "zero?" test since b is always
decreasing.  With a C debugger, this would still be found with relative ease,
albeit with more noise from statements which will never cause the issue.


CONCLUSION
==========

In conclusion, I think that abstracting over control flow in programs may have
been a massive misstep for program readability.  By simply adhering to a
structure where the programmer defines multiple "basic blocks" which follow a
few easy to ensure properties, a function can be made not only easier to
understand, but easier to debug as well.  I firmly believe I have only
scratched the surface with this topic, and will probably be writing more about
it in the future.


MISC NOTES I COULDN'T LOGICALLY FIT IN
======================================

Some may be better written than others...  This is mostly compiled from a sheet
of notes I was taking while coming up with this concept.  They are here mostly
for additional ideas and talking points.

* The current implementation of Elehtre is implemented as a macro in Racket.
  This means Racket's standard control flow structures are still possible to
  use.  This breaks the concept of basic blocks, and therefore they should be
  avoided at all cost.

* The choice to define local variables outside the scope of the basic blocks is
  mainly a consequence of not being able to have sub-scopes or sub-blocks
  without making things ugly.  Potentially an interesting idea would be to
  introduce lambda/elh or some other way to introduce smaller scope blocks.

* If implemented in a functional style (using CPS), each basic block is
  effectively turned into a lambda in a letrec.  Since they will never actually
  pass each other as values (you can't have a label as an argument to
  something), they are all effectively first-order lambdas.  This means we can
  do some very interesting optimizations to them.

* The thing which makes the goto statement bad practice in other languages is
  not a problem with this notion of basic blocks.  Goto being bad is mostly due
  to the unclear control flow which this introduces.  This is usually a
  consequence of languages which allow jumping to code in another lexical
  scope.  This is not a problem here because we have no notion of code blocks
  which have their own lexical scope.

* The ideal realization of this concept would likely be similar to how it is
  currently implemented as a Racket macro.  It would likely be beneficial to
  have it as a DSL which can be embedded in other source code for when behavior
  of a function is complex enough to warrant it.

* This structure lends itself really nicely to manually-written parsers or
  DFAs.