The last version of hoc defined in UPE, hoc6 provides some major features that complete its transition from calculator to minimally-useful scripting language.

User-defined subroutines

Users can now define their own subroutines to create reusable behavior. The implementation changes for this feature are probably—with the exception of our transition from hoc3 to hoc4—the largest overall.

Improved Print Statement & String Literals

The print statement is much improved in hoc6. We can print multiple comma-separated expressions, and even more importantly, string literals!

User Input Support

hoc6 enables hoc programs to read input data from files and/or the console. Together with the enhanced print statement, hoc programs can now prompt the user for input, read pre-calculated data from files, and engage interactively with users.

Feature: User-Defined Subroutines

Subroutines are divided into two categories: functions, which are required to return a value, and procedures, which are required not to. You must decide what kind of subroutine you’re writing up-front, because they use different keywords:

The func keyword defines a function:

func theAnswer() {
    return 42
}

Whereas the proc keyword is used for procedures:

proc tellMeTheAnswer() {
    print 42
}

Procedures are still allowed to use the return keyword in order to exit early, but it must be a “bare return”, with no value.

Subroutines may call other subroutines or themselves; they can also use variables freely. Note, however, that the variables defined inside a subroutine are not scoped; they’ll still be available outside of the routine!

The following example returns the factorial of the global variable x. If x isn’t defined, we’ll get an error when we call it.

func factorialOfX() {
    if (x <= 0) {
      return 1
    }
    f = x
    result = 1
    while (f > 1) {
      result = result * f
      f = f - 1
    }
    return result
}

You can see that all of the variables used inside the function are still available after it returns.

factorialOfX()
./hoc6/hoc: Undefined variable x (on line 15)
x = 5
factorialOfX()
    120
x
    5
f
    1
result
    120

Using Parameters

When defining a subroutine in hoc6, there is no list of formal parameters. Instead, the function/procedure body can freely use the syntax $1, $2, etc. to refer to the first, second, etc. argument. We can use this to make a much nicer factorial function:

func fac() {
  if ($1 <= 0) {
    return 1;
  } else {
    return $1 * fac($1-1)
  }
}

When executing your subroutine, hoc will only verify that such an argument was actually passed when you try to use it.

fac(11)
    39916800
fac()
./hoc6/hoc: Not enough arguments passed to subroutine: fac (on line 10)

Assigning to Parameters

The arguments to a subroutine are passed by value; we are allowed to modify their values without changing them in the caller. Notice how we change $1 at the beginning of compare() below.

func compare() {
  $1 = $1 - $2
  if ($1 < 0) {
    return -1;
  } else if ($1 == 0) {
    return 0;
  }
  return 1;
}

Feature: Enhanced Print Statements

hoc6 has a much-improved print statement. Not only can multiple expressions be printed, e.g:

print PI, sin(PI), cos(PI)

We can also now print string literals, mixed with arbitrary expressions.

print "The sine value of ", PI, " is ", int(sin(PI)), "."

Importantly, this is the only functionality supported for strings. They may not be:

• Stored in a variable
• Returned from a function
• Used within an expression

Feature: Reading User Input

In hoc6, we add a new builtin:

read(varName)

This allows our hoc programs to read user input into a variable and check that the input was valid in a single call.

Specifying Input Sources

First, when starting hoc, we can specify a set of one or more input files, and/or stdin. The read(varName) function will read from one file at a time; when a file is exhausted, hoc transparently moves to the next file.

We’d use the command ./hoc6 datafile to read input from datafile, and ./hoc6 - to read from stdin (presumably, the console).

This can be combined arbitrarily. The following shippet first reads variables from two static files, and once they’re exhausted, will read any remaining data from stdin.

./hoc6 input-file1 input-file2 -

Using Input Data in hoc6

To read a double from our current input sources, you can use the read(myVar) statement. hoc responds to the read request as follows:

1. hoc will attempt to read a double from the current input source

2. If the data is valid, it will be stored into the variable named myVar, and read(myVar) will return 1. If we are out of data, myVar is set to 0 and read(myVar) returns 0. If the data was invalid, we get an exec_error.

This allows us to write programs that interactively use stdin during execution, such as:

> ./hoc -
{
  print "Enter some numbers; press EOF when finished: \n"
  sum = 0
  while (read(x)) {
    sum = sum + x
  }
  print "The sum is: ", sum, "\n"
}
Enter some numbers; press EOF when finished:
1 2 3 4 5 6 7 8
<Ctrl-D pressed>
The sum is: 36
<We can continue using hoc here>

Implementation: Defining Subroutines

We can think of a user-defined subroutine as a named set of machine instructions that are permanently installed in the hoc virtual machine. When we define a subroutine, we install the instructions, but we don’t execute them. This is a significant change; until now, hoc has executed all top-level statements as soon as they’re recognized.

We’ll break down the changes into meaningful areas, as described below. step-by-step. Since procedures and functions only differ in their return values, our discussion applies to both.

1. Definition Syntax - We need to support the syntax for creating named blocks of code
2. Subroutine Addresses - Because subroutines live in our machine’s program storage area, we need to be able to refer to “addresses” inside the prog area.
3. Reserving prog space - Previously, our hoc machine overwrote whatever code had been installed in prog as soon as it was executed. We need a way to mark subroutine instructions as “reserved” so that they are not overwritten by new statements.

Step 1: Declaration Syntax

First, let’s add the ability to recognize a subroutine definition. We have two kinds of subroutines, so we should examine their components:

func subrName() {
  <statements>
}

Some components of this syntax we already have; the block of statements can nicely be handled by stmtlist, for example.

However, we’ll need to add the func & proc keywords, as well as adding parser actions to associate the subroutine’s name Symbol with its instructions.

New Keywords

Like loops and conditionals, it’ll be helpful to have new tokens—PROC_KW and FUNC_KW—for our “introductory” keywords proc and func. This will let us take action before any other components of the declaration are parsed.

-%token  <hoc_symbol>    IF_KW ELSE_KW PRINT_KW WHILE_KW
+%token  <hoc_symbol>    IF_KW ELSE_KW PRINT_KW WHILE_KW FUNC_KW PROC_KW

The keywords must also be added to our language builtins.

static struct hoc_keyword {
  const char *name;
  int         token_type;
} keywords[] = {
    {"if", IF_KEYWORD},
    ...
+   {"func", FUNC_KW},
+   {"proc", PROC_KW},
    {NULL, 0},
};

Subroutine Names & Symbols

Once we’ve found a func or proc keyword, we want to parse the subroutine’s name, and create an associated Symbol object. To that end, we’ll need a new Symbol type; in fact, we’ll define two, so that we can handle the differences in return-value behavior. For lack of a better alternative, we’ll name them UPROC and UFUNC, for procedures and functions respectively.

  %token  <hoc_value>    NUMBER
- %token  <hoc_symbol>   VAR CONST BUILTIN UNDEF
+ %token  <hoc_symbol>   VAR CONST BUILTIN UNDEF UFUNC UPROC
  %type   <hoc_symbol>   assignable

The rules for naming a function will be the same as those for naming any other symbol, so we can reuse the VAR token for parsing a subroutine’s name. However, when we eventually call a subroutine, we’ll need to be able to differentiate them from variables and builtin functions, so we create a small wrapper, subr_decl, to override the installed Symbol’s type. This is the same pattern we used for assignable before, to handle VAR vs CONST symbols.

First, we’ll declare that, like our assignable wrapper, subr_decl procuces a Symbol.

  %token  <hoc_value>    NUMBER
- %type   <hoc_symbol>   assignable
+ %type   <hoc_symbol>   assignable subr_decl

The production for a subr_decl is easy, since we have our introductory keywords letting us know when a declaration has begun. Our only job is to override the Symbol.type installed by the lexer.

+ subr_decl:      PROC_KW VAR
+                 {
+                     $2->type = UPROC;
+                     $$ = $2;
+                 }
+         |       FUNC_KW VAR
+                 {
+                     $2->type = UFUNC;
+                     $$ = $2;
+                 }
+         ;

Recognizing Subroutine Definitions

We can complete our language support for subroutine definnitions by recognizing their overall shape, including the body.

Modeling ourselves after our if and while constructs, we note that these declarations should be statements, and we can use the stmt production to recognize their bodies.

Like all statements, procedure declarations return the address at which they begin. These declarations are entirely defined by their body, so we’ll return the address of their body stmt.

  stmt:           expr { install_instruction(inst_pop); }
          |       '{' stmtlist '}' { $$ = $2; }
+         |       subr_decl '(' ')' stmt
+                 {
+                     $$ = $4;
+                 }

Step 2: Subroutine Addresses

Since user-defined subroutines are really just a set of instructions, a Symbol referring to a subroutine is really holding the address of the associated instructions.

It seems like the time to add an Addr member to the Symbol.data union, but unfortunately, this causes a new problem. Remember that the MachineCode struct already contains a Symbol pointer, because that’s how we represent symbol-table references. This causes cyclic dependencies between the Symbol and MachineCode types.

We can solve this by moving our forward declaration of MachineCode & Addr above our Symbol definition in hoc.h, and let the compiler resolve the full struct layout.

+ ///----------------------------------------------------------------
+ /// Addresses (Shared by multiple types)
+ ///----------------------------------------------------------------
+ typedef struct MachineCode MachineCode;
+ typedef MachineCode       *Addr;

...

  struct Symbol {
    char *name;
    short type;  // Generated from our token types
    Symbol *next;
    union {
      double             val;
+     Addr               addr;
      struct BuiltinFunc func;
    } data;
  };

+ ///----------------------------------------------------------------
+ /// Machine Code
+ ///----------------------------------------------------------------
...
- typedef struct MachineCode MachineCode;
- typedef MachineCode       *Addr;

Step 3: Installing Subroutines

We need a way to “install” routines into our machine permanently, so that we can execute them multiple times. The biggest obstacle to this process is our machine_reset_program() function, which resets progp every time we execute a parsed statement. We need a way to prevent our subroutine bodies from being overwritten.

One workable method is to mark all space from prog to the end of the procedure as “reserved”. Instead of resetting progp back to the beginning of program memory, we’ll use a new variable, prog_start, which indicates the first non-reserved word that we can use.

  MachineCode prog[PROGSIZE];
+ Addr        prog_start = prog;  // No installation above this address
  Addr        progp;              // Next free location for code installation
  static Addr pc;                 // the current location in the executing program

The prog* variables have the following relationship:

Now, when we define a routine, we’ll preserve its code by shifting prog_start to just after its body. This is handled by reserve_subr, a new machine function. That function also updates the given Symbol to point to the location where the subroutine begins.

/**
 * Reserves all currently-installed code as a subroutine, under Symbol
 * `subr_sym`. The value of `subr_sym` will be updated to the address
 * of the installed routine. Ensures that the code will not be
 * overwritten by future installations, even after a machine reset.
 */
void reserve_subr(Symbol *subr_sym);

  Addr install_code(MachineCode mc) {
    *progp = mc;
    Addr result = progp++;  // return location of THIS instruction
    return result;
  }

+ void reserve_subr(Symbol *subr_sym) {
+    subr_sym->data.addr = prog_start;
+    prog_start = progp;
+ }

Then, we make machine_reset_program() aware of prog_start, so that we never again overwrite any code between prog and prog_start.

void machine_reset_program(void) {
  stackp = stack;
- progp = progp;
+ progp = prog_start;

Finally, we update our parser action for subroutine-declaration statements to call our new reservation function and populate the Symbol value. Now, writing a subroutine declaration will install code, but won’t execute any!

  stmt:      expr { install_instruction(inst_pop); }
        |    '{' stmtlist '}' { $$ = $2; }
        |    subr_decl '(' ')' stmt
             {
+                reserve_subr($1);
                 $$ = $4;
             }

Breakpoint: Test your Implementation

If you are following along, now is a good time to test your implementation. We can do that by adding a temporary expr production that understands how to produce a value for an installed declaration.

%%
expr: ...
...      |   UPROC
             {
                 $$ = install_instruction(inst_pushlit);
                 install_literal($1->data.addr - prog);
             }
         |   UFUNC
             {
                 $$ = install_instruction(inst_pushlit);
                 install_literal($1->data.addr - prog);
             }

Now, using the function/procedure name as a variable will evaluate to its address, relative to prog. As expected, a more complex body (like calling a builtin), corresponds to a larger block of instructions.

./hoc6/hoc
proc f1() { x = 123 + 345 }
proc f2() { print sin(cos(x+42)) }
proc f3() { y = 10 }
f1
    0
f2
    10
f3
    24

Implementation: Calling Subroutines

hoc now correctly installs our subroutines into permanent storage. We now focus on calling those subroutines, which requires a coordinated dance between the caller and called code.

The basic idea of executing subroutines in our hoc VM involves a combination of two cooperating instructions:

• subrexec, to enter a named subroutine, saving our current location

• uprocret, to return from a procedure to the saved location. (There’s also a ufuncret instruction, covered when we implement return values.)

We’ll add this functionality in stages:

1. Representing Subroutine Calls & Callers - Whenever we call a procedure, we must keep track of where we will resume execution afterwards. Since subroutines may call other subroutines (or themselves), we need to track an arbitrary stack of callers.

2. Language Changes

3. Executing Subroutines

4. Returning to Callers

Step 1: Representing “Calls”

The bare minimum required for executing a reserved block of code —ignoring, for now, arguments and return values—is the ability to jump to the subroutine’s address, then jump back the caller after executing. The origin / destination data for a call is encoded into a call frame. Unlike most of our objects, the Frame structure has no use outside of the machine module, and so we can define it inside machine.c.

typedef struct Frame {
  Symbol *subr_called;  // the UFUNC/UPROC we have jumped to
  Addr    ret_pc;       // return location
} Frame;

Below is an example of how relationship between the subrexec instruction, the Frame it creates, and the uprocret instruction, which uses the information to return to the caller.

The Call Stack

Because subroutines may call other subroutines (or themselves), a single Frame of call data is not sufficient. Instead, this information is often organized into a stack of per-call data, imaginatively named the call stack. Since a Frame is pushed onto the stack every time a subroutine is invoked, and popped when a routine returns to its caller, the currently-executing routine always has access to its own data at the top of the stack.

#define FRAMELIMIT 100  // Recursion depth limit
static Frame        frames[FRAMELIMIT];
static const Frame *OVERFLOW_FRAME = frames + FRAMELIMIT;
static Frame       *fp = frames;   // Next frame to use

We also add some simple functions for manipulating the frame stack.

/**
 * Push a new frame for a subroutine call onto the frame stack, or fail on
 * overflow.
 *
 * The frame is initialized as a call to Symbol `s`, returning to address
 * `caller_pc`. Caller must initialize all other frame data.
 */
static Frame *frame_push(Symbol *s, Addr caller_pc) {
  if (fp == OVERFLOW_FRAME) {
    exec_error("Call-Stack Overflow while calling '%s'", s->name);
  }

  fp->subr_called = s;
  fp->ret_pc = caller_pc;
  return fp++;
}

/** Pop most recent Frame from the frame stack, or fail on underflow */
static Frame *frame_pop(void) {
  if (fp == frames) {
    exec_error("Call-Stack Underflow while attempting to return");
  }
  return --fp;
}

/** Access top of frame stack, or fail if no Frame exists */
static Frame *frame_peek(void) {
  if (fp == frames) {
    exec_error("Call-Stack Underflow while attempting to peek at top frame");
  }
  return fp - 1;
}

Step 2: The subrexec Instruction

With our new call stack, we can implement the subrexec instruction, which performs the work to actually change our PC location and push a new Frame onto our stack. This instruction is always two words long, since we also need the Symbol which points to our procedure.

To actually run the subroutine, we use a recursive execute() call, using Symbol->data.addr as the pc value.

int inst_subrexec(void) {
  Symbol *sym = (pc++)->symbol;
  Frame *f = frame_push(sym, pc);

  execute(sym->data.addr);
  return 0;
}

Sidenote: Why Recurse? (Or skip

While it may seem as though we could simply change the value of the PC in order to “jump” to the subroutine, a nested execute() call is more compatible with with our implementation of ifcode and whilecode. Since those instructions use recursion, a direct-jump subroutine implementation without using recursion would lead to executing code in C stack frames we would not expect.

As an example, consider the following hoc program.

proc sillyCode() {
  if (2) {
    if (3) {
      print 1
      return
    }
    print 4
  }
  print 5
}
{
 if(1) {
   sillyCode()
   print 2
 }
 print 3
}

1
2
4
5
3

Because our ifcode instructions recurse, we’re inside 4 execute() functions by the time we reach print 1:

1. Main execute() from our REPL
2. execute() inside inst_ifcode for if (1).
3. execute() inside inst_ifcode for if (2).
4. execute() inside inst_ifcode for if (3).

Now, after we finish print 1, we return, and we assume that merely jumps to the instructions for print 2. Since that’s the end of a stmtlist block, the following instruction will be a STOP.

Now things get odd. This will exit the fourth layer of the execute() function, bringing us back to the inst_ifcode we were running for if (3)… inside our procedure! And that will begin running print 4! There are many problematic situations we can create for ourselves in this manner.

Step 3: Subroutine-Call Syntax

To install the subrexec instruction, we must add the language rules for calling a function or procedure. For now, we’ll disallow specifying any arguments, so the address we produce for the parser will just be the instruction for calling the procedure / function. Notice that procedure calls, which don’t return a value, must be statements, as they don’t leave a value on the stack.

%%
stmt: ...
     |        UPROC '(' ')'
              {
                  $$ = install_instruction(inst_subrexec);
                  install_ref($1);
              }

Function calls are expressions, and so they can be used inside conditions, etc. (The job of placing a value onto the data stack will be handled by the return statement of the function; trying to call a function at this point will cause errors!)

%%
expr: ...
     |        UFUNC '(' ')'
              {
                  $$ = install_instruction(inst_subrexec);
                  install_ref($1);
              }

Step 4: Returning to our Caller

Our procedures must, at some point, return to their caller. We need a facility to “jump back” to our calling code. Since we’re executing recursively, this means we need to add a way to signal that it’s time to return from our current execute() call, and update the pc value to match our return address.

For hoc6, we will use a simple implementation, adding an is_returning flag that is examined by execute(). Whenever that flag is true, the VM knows it should just be unwinding nested execute calls, so the execute() function returns immediately, without incrementing the pc value again or executing anything.

That flag should stay true until we find ourselves back int the inst_subrexec function, since we’ve returned from the called subroutine. At that point, we can safely set the flag to false, knowing that the return instruction has already updated the PC.

You can see a visual representation of this flow below:

1. subrexec runs within some execute() call (dotted). It finds the procedure address, and starts its own execute() flow.
2. This flow runs instructions; eventually we reach a uprocret instruction
3. uprocret sets pc = frame.ret_pc, and sets the is_returning flag
4. execute() sees the flag is enabled, and returns to subrexec
5. subrexec disables is_returning, and returns to its enclosing execute() call. the pc value is still set to the value from uprocret and not updated - execution continues correctly.

Machine Changes

First, we must add the flag for is_returning:

  #define FRAMELIMIT 100  // Recursion depth limit
  #define OVERFLOW_FRAME (frames + FRAMELIMIT)
  static Frame  frames[FRAMELIMIT];
  static Frame *fp = frames;   // Next frame to use
+ static bool   is_returning;  // true when returning from a user subroutine

Next, we’ll add the uprocret instruction; it must:

• Pop the current Frame from our frame stack, so we know our return address
• Set the pc to that return address, so that execution can resume in our caller.
• Mark is_returning true, so that the next execute() iteration returns early, and we may return to subrexec.

int inst_uprocret(void) {
  Frame *f = frame_pop();
  is_returning = true;
  pc = f->ret_pc;
  return 0;
}

Finally, we update execute to respect this state.

void execute(Addr start_addr) {
  pc = start_addr;
+ is_returning = false;
- while (!is_stop_inst(pc)) {
+ while (!is_stop_inst(pc) && !is_returning) {

An Issue: Loops and Conditionals

There’s one other aspect of our execution flow that must be considered before we’re done. To see it, consider the following hoc program, and decide what output will result when running it.

tester = 0
proc earlyReturnTest() {
  if (tester > 0) {
    print 2
    return
  }
  print 1
}

The reason for this bug lies in our current implementation of the ifcode and whilecode instructions, and the nested execution flow we’re using. Because ifcode and whilecode also overwrite the pc value after their nested execute() calls, they may override the pc value just set by uprocret!

Consider the following flow:

Looking back to our example, the return keyword inside our function sets pc and is_returning. We immediately return to the ifcode function, whose nested execute just ended. But the inst_ifcode function also sets the PC value, overriding our return location.

The relevant parts of hoc5’s inst_ifcode() are commented below:

int inst_ifcode(void) {
  Addr ifbody_addr = pc[0].addr;
  ...
  Addr end_addr = pc[2].addr;
  Addr cond_addr = pc + 3;
  execute(cond_addr);
  Datum d = stack_pop();
  if (d.value) {
    execute(ifbody_addr);  // uprocret changes our PC inside here
  }
  pc = end_addr;           // and it's overwritten here...  :(
  return 0;
}

How can we make our return keyword force its way past any enclosing if and while blocks, until it reaches its parent subrexec instruction?

“Bubbling” Returns via is_returning Checks

As the UPE authors suggest, a simple (if hacky) fix, is to make these instructions aware of the our is_returning state, since they are part of our ‘pc-change’ flow. Before making any manual changes to the pc value, we check whether we’re actually returning (and so should stop executing). This lets us “bubble up” from a return statement, through any enclosing ifs or whiles, to the subroutine we’re returning from! Here’s our fixed ifcode flow:

The actual changes are minor:

inst_ifcode

  int inst_ifcode(void) {
    ...
    execute(cond_addr);
    Datum d = stack_pop();  // must be value
    if (d.value) {
      execute(ifbody_addr);
    } else if (maybe_elsebody.type == CT_ADDR) {
      execute(maybe_elsebody.addr);
   }
}

-   pc = end_addr;
+   if (!is_returning) {
+     pc = end_addr;
+   }
    return 0;
  }

inst_whilecode

  int inst_whilecode(void) {
    Addr body_addr = (pc++)->addr;
    Addr end_addr = (pc++)->addr;
    Addr cond_addr = pc;

    while (true) {
+     if (is_returning) {
+       return 0;  // PC is already set to the appropriate address
+     }

      execute(cond_addr);
      if (stack_pop().value) {
        execute(body_addr);
      } else {
        break;
      }
    }

    // condition false
    pc = end_addr;
    return 0;
  }

Adding return Statements

To allow users to trigger the return, we add a return keyword to our token declarations and language builtins:

- %token  <hoc_symbol>  IF_KW ... FUNC_KW PROC_KW
+ %token  <hoc_symbol>  IF_KW ... FUNC_KW PROC_KW RETURN_KW

static struct {
    const char *name;
    int         token_type;
  } keywords[] = {
      {"if", IF_KW},
      {"else", ELSE_KW},
      {"func", FUNC_KW},
      {"proc", PROC_KW},
      {"print", PRINT_KW},
      {"while", WHILE_KW},
+     {"return", RETURN_KW},
      {NULL, 0},
  };

And a return statement to install the uprocret machine instruction. The return statement has an interesting new feature: it should only be used while defining a subroutine.

Adding the keyword itself is straightforward; we add the RET_KEYWORD to hoc.y and the associated "return" string to builtins.c.

But in order to prevent users from writing a return statement outside of a subroutine, we’ll need to know, while executing the parser action, whether we’re currently defining a subroutine or not.

To do this, we’ll add a new piece of parser state: current_subr.

/** Tracks the symbol for the subroutine currently being parsed (if any). */
Symbol *current_subr = NULL;

While our parser is parsing a subroutine, we want this variable to track the Symbol of that subroutine. Once we’ve finished parsing the routine, we must reset it to NULL. This is most easily done inside our subr_decl action:

  subr_decl:      PROC_KW VAR
                  {
                      $2->type = UPROC;
+                     current_subr = $2;
                      $$ = $2;
                  }
          |       FUNC_KW VAR
                  {
                      $2->type = UFUNC;
+                     current_subr = $2;
                      $$ = $2;
                  }
          ;

And then removing the definition after parsing the body

  stmt: ...
    |             subr_decl '(' ')' stmt
                  {
                     reserve_subr($1);
+                    current_subr = NULL;
                     $$ = $4;
                  }

Once we have access to the current subroutine, enforcing that return statements can’t happen outside of them is trivial.

stmt: expr { install_instruction(inst_pop); }
...
+     |  RETURN_KW
+        {
+             if (current_subr == NULL) {
+                 exec_error("Syntax error - "
+                            "`return` keyword used outside of a subroutine");
+             }
+             if (current_subr->type != UPROC) {
+                 exec_error("Syntax error - "
+                            "bare return used outside of a procedure");
+             }
+            $$ = install_instruction(inst_uprocret);
+        }

“Fall Through” Returns

It’s all well and good to allow users to return from their procedures, but what if they forget, or their procedure simply runs until it ends? We need to make absolutely sure that our procedures will return to their caller’s location. To do this, we can simply force every procedure to end with a uprocret instruction, during our parser action for procedure declarations. At this point, the procedure body has been installed, so we can safely add one more instruction to the end of the procedure’s body before reserving space for it in our machine.

stmt:  ...
    |   subr_name '(' ')' stmt
        {
+           /*
+            * Note: the order of these two lines matters!
+            * `uprocret` should be part of the subr body,
+            * so reserve space *after* installing it.
+            */
+           install_instruction(inst_uprocret);
            reserve_subr($1);
            current_subr = NULL;
            $$ = $4;
        }

Breakpoint: Test your Implementation

This is another good place to test your implementation; no additional code should be required for defining & calling procedures.

Implementation: Passing Arguments

At this point, we can declare procedures and then call them. Next, we will implement passing data into our subroutines, via arguments, and then accessing that data inside our subroutine bodies.

Arguments to our subroutines will be managed on our data stack, must be sure to add and remove them on entrance and exit.

Step 1: Designing Argument-Passing

First, we must decide how to encode arguments for our machine to find when executing subrexec. We’ve seen one way of passing arguments already in hoc3, when using BUILTIN functions. Those functions had a fixed number of arguments; those values were stored on the data stack, and each inst_callN variant knew how many to remove.

Our subroutines, on the other hand, allow an arbitrary number of arguments. During a call, arguments will be placed onto the (data) stack, and stay there for the entire duration of the call. In order for the subroutines to use the arguments, we must be able to locate them on the stack; furthermore, to avoid invalid memory accesses, we should check that an argument exists before trying to access it.

We’ll encode the number of arguments and their stack location inside our Frame during our subrexec call. The number of arguments will be generated as part of the subrexec instruction, to ensure that we only access paramters that actually exist. The stack location is only known at call time, so we’ll update our subrexec instruction to populate that value.

Then, our subroutine bodies will be able to generate instructions that can lookup argument values, using this data from the current Frame.

First, we’ll update our Frame struct with fields to represent arguments passed.

  typedef struct Frame {
    Symbol *subr_called;  // the UFUNC/UPROC we have jumped to
    Addr    ret_pc;       // return location
+   Datum  *argp;         // pointer to first argument
+   int     arg_count;    // number of arguments
  } Frame;

Step 2: Argument-Passing Syntax

Arguments add two additional responsibilities to our parser. The first is some additional complexity around the addresses of our procedure-call statements. Consider the hoc statement:

callMyProcedure()

Previously, this stmt generated a single, two-word instruction, subrexec, and the stmt production for the call produced the address of the first word.

%%
stmt: ...
     |        UPROC '(' ')'
              {
                  $$ = install_instruction(inst_subrexec);
                  install_ref($1);
              }

Now, if we instead call a subroutine that requires arguments, like:

add3(6, 14, 7)

Then the address of the subrexec instruction is not sufficient. Like BUILTINs, we require the address where our argument expressions begin to be generated.

The second need is our requirement that the parser should tell us how many arguments were passed in a given call, so that it can generate our new version of subrexec, which includes the number of arguments.

You can see the required information in the diagram below:

We need a new piece of syntax for tracking the start address and number of argument expressions in a call.

Tracking Integer Values

To track a “count” value, we’ll add yet another new value type to our parser – integer. This’ll be useful for cases where we want to refer to an “index” or “count”, rather than trying to use a double to specify a whole number value, such as “3 arguments passed” or “get argument for parameter 2”.

  %union {
    double hoc_value;
    Symbol *hoc_symbol;
      Addr hoc_address;
+     int  hoc_integer;
  }
  %type   <hoc_symbol>    assignable subr_name

New Syntax: Argument Lists

Since we need two new pieces of information, we’ll create two new non-terminals to represent them inside our subroutine calls.

First, we’ll create a non-terminal, arglist, that accepts a list of expressions, and produces the number of expressions in that list.

  %type   <hoc_symbol>    assignable subr_decl
+ %type   <hoc_integer>   arglist

For our arglist production, the expressions themselves are still installed by the expr nonterminal; the arglist action only cares about how many expressions it has seen. It counts them by using itself recursively; we also include a special case for a single argument.

%%
arglist:        /* nothing */ { $$ = 0; }
        |       expr { $$ = 1; }
        |       arglist ',' expr { $$ = $1 + 1; }

Tracking Argument Addresses

Next, we need to track the address where our argument expressions begin to be installed. We’ve done this kind of thing before, with the end production in our if and while statements. We create a new args_start production to to “mark our place” when we start parsing an argument list.

It produces an address:

- %type <hoc_address>   assign call end expr if stmt stmtlist while
- %type <hoc_address>   args_start assign call end expr if stmt stmtlist while

And it operates almost like the end production; however, it doesn’t install anything.

%%
args_start:     /* nothing */ { $$ = progp; }
        ;

Finally, we can add these nonterminals into our procedure and function call syntax.

  stmt:           expr { install_instruction(inst_pop); }
          |       '{' stmtlist '}' { $$ = $2; }
-         |        UPROC '(' ')'
+         |        UPROC '(' args_start arglist ')'
                  {
-                     $$ = install_instruction(inst_subrexec);
+                     install_instruction(inst_subrexec);
                      install_ref($1);
+                     install_literal($4);
+                     $$ = $3;
                  }

  expr:           NUMBER
  ...
-         |       UFUNC '(' ')'
+         |       UFUNC '(' args_start arglist ')'
                  {
-                     $$ = install_instruction(inst_subrexec);
+                     install_instruction(inst_subrexec);
                      install_ref($1);
+                     install_literal($4);
+                     $$ = $3;
                  }

Locating Arguments on the Stack

Then we’ll need to update inst_subrexec to handle the new information in our instruction format; upon reaching an subrexec call, we’ve got the arguments for the call at the top of the stack, so we set our argp value to point to the first argument’s Datum. Since we’ve got a stack of arguments, the first argument is exactly arg_count indices behind our stackp pointer.

  int inst_subrexec(void) {
    Symbol *sym = (pc++)->symbol;
+   double  arg_count = (pc++)->literal;

    Frame *f = frame_push(sym, pc);
+   f->arg_count = arg_count;
+   f->argp = stackp - f->arg_count;

    execute(sym->data.addr);
    is_returning = false;
    return 0;
  }

Step 3: Evaluating Parameters

In order to actually use our arguments within the body of a procedure or function, we need to transform references like $1, $2, etc. into stack accesses, which either fetch or overwrite a value on the stack.

argget

The basic idea will be to parse a parameter reference $k into a new argget instruction. This instruction is two words long; the second word, k, specifies the parameter number we want to access. The machine will:

1. Verify that k is within the current frame’s arg_count
2. Find the argument value on the stack using the current frame’s argp
3. Push a copy of the argument value onto the top of the stack

argset

Assigning a value to an argument will work similarly; the value at the top of the stack replaces the Datum value for argument k. It’s then put back at the top of the stack, since assignments are expressions.

Language Changes: Using Arguments

First, we’ll need a way to recognize parameter references, and turn the reference $k into the literal integer k.

Lucky for us, we just added a new “integer” value-type into our language, so we can associate a new PARAM_NUMBER token with that type. (Remember: It’s capitalized because it’s a terminal.)

  %type   <hoc_symbol>    assignable udef_name
  %type   <hoc_integer>   arglist
+ %token  <hoc_integer>   PARAM_NUMBER

Then, we can update our yylex() function to handle parameters as well. A $ with no prefix or other surrounding characters is only valid as a parameter reference, so we can place this conditional logic anywhere before our final switch statement.

If scanf fails to read an integer, or we get a non-positive integer value, we consider it a lexing failure. This allows more informative error messages, but whether to perform this much semantic validation inside your lexer is a matter of opinion.

  int yylex(void) {
    int c;
...

    if (c == '\n') {
      line_number++;
    }

+   // Parse parameters
+   if (c == '$') {
+     if (scanf("%d", &yylval.hoc_integer) != 1) {
+         exec_error("Invalid parameter specification", "");
+     } else if (yylval.hoc_integer <= 0) {
+         exec_error("Parameters must be nonnegative", "");
+     }
+     return PARAM_NUMBER;
+   }

We can use our PARAM_NUMBER token to write new expr productions for evaluating or assigning a parameter. Like the productions for return statements, these should only be allowed while defining a procedure.

expr:
...
+    |   PARAM_NUMBER
+        {
+            if (current_subr == NULL) {
+                exec_error("Syntax error - "
+                           "Parameter '$%d' not allowed here", $1);
+            }
+            $$ = install_instruction(inst_argget);
+            install_literal($1);
+        }
+    |   PARAM_NUMBER '=' expr
+        {
+            if (current_subr == NULL) {
+                exec_error("Syntax error - "
+                           "Parameter '$%d' not allowed here", $1);
+            }
+            $$ = install_instruction(inst_argset);
+            install_literal($1);
+        }
     |       expr '+' expr   { install_instruction(inst_add); }

Machine Changes: argget and argset

The inst_argget and inst_argset instructions use the Frame.argp pointer to access the correct location in the stack. The only arithmetic required is converting the parameter numbers into zero-indexed offsets.

int inst_argget(void) {
  int    arg_number = (pc++)->literal;
  Frame *current_frame = frame_peek();
  if (current_frame->arg_count < arg_number) {
    exec_error("Subroutine '%s' uses parameter %d, but only got %d.",
               current_frame->subr_called->name,
               arg_number,
               current_frame->arg_count);
  }
  stack_push(current_frame->argp[arg_number - 1]);
  return 0;
}

int inst_argset(void) {
  int    arg_number = (pc++)->literal;
  Frame *current_frame = frame_peek();
  if (current_frame->arg_count < arg_number) {
    exec_error("Subroutine '%s' uses parameter %d, but only got %d.",
               current_frame->subr_called->name,
               arg_number,
               current_frame->arg_count);
  }
  Datum d = stack_pop();
  current_frame->argp[arg_number - 1] = d;
  stack_push(d);
  return 0;
}

Removing Arguments on Return

There’s one last detail to handle related to argument values. We need to remove them when we return from our subroutines. To that end, we add a small helper function to the machine module, so that both procedures and functions can remove their arguments once complete.

/**
 * Reset any machine state indicated by the given frame. This includes:
 * - Removing any arguments from the stack for the call.
 * - Resetting the program counter
 * - Setting global "returning" flag
 */
static void return_from_frame(Frame *f) {
  // remove args from stack
  while (f->arg_count-- > 0) {
    stack_pop();
  }
  is_returning = true;
  pc = f->ret_pc;
}

Our uprocret instruction can then be made a little simpler.

int inst_uprocret(void) {
    Frame *f = frame_pop();
-   is_returning = true;
-   pc = f->ret_pc;
+   undo_frame_state(f);
    return 0;
+ }

Implementation: Functions & Return Values

Finally, we can make the finishing touches that allow us to make functions work. Since calling a function produces a value, a function call must be an expression rather than a statement. Furthermore, a function must include the return keyword (with a value), which we’ll need to check at runtime rather than parse-time.

Step 1: Return Values & the Stack

The ufuncret instruction is used for returning from a function, it should be used just after our return value has been produced and pushed onto the stack. There’s just one problem: there’s a bunch of arguments underneath it, and they need to go! So, the ufuncret instruction removes the top stack value, saves it, then calls return_from_frame to remove the arguments from the stack. After that’s complete, we can re-push the expected return value onto the top of the stack, which will be available to the caller once control returns to them.

int inst_ufuncret(void) {
  Frame *f = frame_pop();
  Datum  result = stack_pop();
  undo_frame_state(f);
  stack_push(result);
  return 0;
}

Step 2: Adding a value-return statement

The format of a value-return is simply return <expr>, which means that the expression will already have pushed the value onto the data stack by the time we install the return instruction. This makes the action for value-return statements simple; it’s only real job is verifying that we’re actually inside a function; otherwise, we disallow the installation of a ufuncret instruction.

    |       RETURN_KW expr
+         {
+             if (current_subr == NULL) {
+                 exec_error("Syntax error - "
+                            "return keyword used outside of a subroutine");
+             }
+             if (current_subr->type != UFUNC) {
+                 exec_error("Syntax error: -"
+                            "`return <expr>` used outside of a function");
+             }
+             install_instruction(inst_ufuncret);
+             $$ = $2;
+         }
+

Step 3: Enforcing Return Values

When a function is installed, our parser will still end it with the uprocret instruction, since we use the same code to install both types of subroutine. Unlike procedures, however, functions should never reach that instruction. We should always hit a ufuncret instruction first.

To make sure users understand what they did wrong, we will update the uprocret instruction to raise an error at runtime if it detects that we’re inside a function, since that means we forgot to return a value

int inst_uprocret(void) {
    Frame *f = frame_pop();

+   if (f->def_called->type != UPROC) {
+     exec_error("Function '%s' does not return a value", f->subr_called->name);
+   }

    undo_frame_state(f);
    return 0;
  }

And with that, our function implementation should be complete!

Implementation: Enhanced Print Statements

We add a (very) minimal implementation of strings for use in print statements. This is their only allowed use; in particular, they cannot be used as variables. In this version of hoc, they also leak memory.

The implementation adds a new string-printing instruction, which has a two-word layout:

This only requires support for parsing and installing strings into our machine’s memory.

Step 1: Add Dynamic Strings

We begin by writing a (very) small dynamic-string module, hoc6/str.c, based on the common len + capacity implementation. For the sake of brevity (hah), we don’t discuss the implementation here, but we’ll come back to strings in ehoc. Its interface is all we’re interested in.

typedef struct str str;

/** Allocate a string; runtime error on allocation failure */
str *str_new(void);

/** Append a character to the end of a string */
bool str_append(str *s, char c);

/**
 * Get a "view" of string `s` for use as a valid, NUL-terminated C
 * string. The pointer returned is non-owning, and will be
 * invalidated by any manipulations made to the string.
 *
 * In particular, if the caller wishes to store the resulting char
 * buffer for other uses, it should be copied.
 */
const char *str_view(str *s);

/** Clear the string's contents */
void str_clear(str *s);

/** Deallocate `s`, freeing its memory. */
void str_free(str *s);

We’ll use this library to allocate storage for strings as they’re parsed.

Step 2: Lexing & Parsing Changes for Strings

The biggest change required for string parsing is recognizing string literals and allocating strings for them during the lexing process.

First we add the STRING token

  %union {
    double hoc_value;
    Symbol *hoc_symbol;
      Addr hoc_address;
      int hoc_integer;
+     str *hoc_string;
  }

  %token  <hoc_value>     NUMBER
  %token  <hoc_symbol>    VAR CONST BUILTIN UNDEF UFUNC UPROC COMMAND
  /* These keyword symbols are efectively singletons */
  %token  <hoc_symbol>    IF_KW ELSE_KW PRINT_KW WHILE_KW FUNC_KW PROC_KW RETURN_KW READ_KW
  %type   <hoc_symbol>    assignable udef_name
  %type   <hoc_integer>   arglist
  %token  <hoc_integer>   PARAM_NUMBER
+ %token  <hoc_string>    STRING

We’ll force all strings to be double-quoted (though they may contain escaped quotes), and so once we see a double-quote, we can collect characters until we reach the next one.

  int yylex(void) {
    ...
    // Parse parameters
    ...
+   // Parse strings
+   if (c == '"') {
+     str *s = str_new();
+     while (true) {
+       c = getchar();
+       if (c == '"') {
+         break;
+       }
+       if (c == EOF || c == '\n') {
+         exec_error("String wasn't closed: '%s'", str_view(s));
+       }
+       str_append(s, escaped(c));
+     }
+     yylval.hoc_string = s;
+     return STRING;
+   }
+
    // Get numbers
    ...

The only interesting detail is how to escape special characters; the escaped function allows us to handle this transparently.

/**
 * If c is '\': Returns next input character, string-escaped.
 * Otherwise: returns c
 */
int escaped(char c) {
  // Each escaped character is followed by its output char
  static char translations[] = "b\b"
                               "f\f"
                               "n\n"
                               "t\t";

  if (c != '\\') {
    return c;
  }

  c = getchar();
  char *cp = strchr(translations, c);

  // islower() used so that we don't match the output chars or NUL
  if (islower(c) && cp != NULL) {
    return cp[1];
  }

  return c;
}

Sidenote: Allowing arbitrary-length symbols

While we’re working on yylex(), we might as well fixup our other use of static strings in hoc: Symbol names. We only allowed 100-character identifiers before, whereas we could easily support more than that. We replace our use of a static buffer with a str object instead. (Note that because install_symbol copies the string passed to it, we are safe to pass it a str_view here.)

If you want to leave the identifier limit in place, you could do so by leaving the hoc.h constant and while condition check in place. Otherwise, you can remove SYMBOL_NAME_LIMIT from hoc.h as well.

We’ll use a single static str for all lexing calls; there’s no reason to allocate & free memory for these repeatedly. Its internal memory use will expand to the maximum identifier length used during hoc’s runtime.

  int yylex(void) {
+   static str *symbol_str = NULL;
    int c;

When we find the beginning of a symbol, we’ll reset our string, instead of setting up a buffer.

    // Get numbers
    ...
    if (isalpha(c)) {
      Symbol *s;

-     char buf[SYMBOL_NAME_LIMIT + 1];
-     size_t nread = 0;
+     // reset symbol string for new input
+     if (symbol_str == NULL) {
+       symbol_str = str_new();
+     } else {
+       str_clear(symbol_str);
+     }
  ...

Then, we can remove the SYMBOL_NAME_LIMIT checks and replace character updates with str functions.

      do {
-         buf[nread++] = c;
+         str_append(symbol_str, c);
          c = getchar();
-     } while (nread < SYMBOL_NAME_LIMIT && (isalpha(c) || isdigit(c)));
+     } while (isalpha(c) || isdigit(c));

-     // Just in case we exceeded the limit
-     while ((isalpha(c) || isdigit(c))) {
-         c = getchar();
-     }
-
      // at this point, we have a non-alphanumeric 'c'
      ungetc(c, stdin);

-     buf[nread] = '\0';
+     const char *buf = str_view(symbol_str);
      if ((s=lookup(buf)) == NULL) {
          s = install_symbol(buf, UNDEF, 0.0);
      }
      yylval.hoc_symbol = s;
      return (s->type == UNDEF ? VAR : s->type);
  }

Step 3: Allow MachineCode to hold strings

We’ll add yet another potential type for MachineCode elements, allowing a word of our VM memory to point to a string.

struct MachineCode {
  CodeType type;
  union {
    double  literal;
    Inst    inst;
    Symbol *symbol;
    Addr    addr;
+   str    *string;
  };
};

Step 4: The prstr instruction

Once our parser can install prstr instructions, actually printing the string is trivial. We use our str_view method to create a C string from the string pointer; since we print it immediately, we don’t need to do any defensive copying. (Make sure to add a prototype for inst_prstr to hoc.h.)

int inst_prstr(void) {
  str *s = (pc++)->string;
  printf("%s", str_view(s));
  return 0;
}

(Note the lack of \n in the output format string. This will be useful in the next output feature: printing multiple expressions)

Step 5: Our Improved print Statement

Now to combine our string-printing functionality with the existing expression-printing.

We’ll replace our print expr statement with a generalized prlist nonterminal.

stmt:    ...
-       |     PRINT_KW expr
-             {
-                 install_instruction(inst_prexpr);
-                 $$ = $2;
-             }
+       |     PRINT_KW prlist
+             {
+                 $$ = $2;
+             }
...

This nonterminal handles any nonzero number of STRING or expr elements, and prints each of them. We can base our list-handling rules on our arglist production.

%%
prlist:         expr
                {
                    install_instruction(inst_prexpr);
                    $$ = $1;
                }
        |       STRING
                {
                    $$ = install_instruction(inst_prstr);
                    install_string($1);
                }
        |       prlist ',' expr
                {
                    install_instruction(inst_prexpr);
                    $$ = $1;
                }
        |       prlist ',' STRING
                {
                    install_instruction(inst_prstr);
                    install_string($3);
                    $$ = $1;
                }

Reading User Input

To complete our minimal I/O implementation, we’ll add features to read data from input files or the user’s terminal. In fact, we’ll allow specifying multiple files on the command line, and proceed from one to the next as they’re exhausted.

The UPE authors add the input-reading code to hoc.y. For hoc6, we’ll instead add a new inputfiles module, though the functionality is the same. We’ll revisit input/output organization in adhoc.

The call-graph for our user-input flow follows the following simplified diagram:

The main program initializes our input sources based on the command-line arguments, using the init_inputfiles interface:

/**
 * Initializes the inputfiles module with the first `filecount`
 * members of the `filenames` array; Each should be a file path.
 */
void init_inputfiles(char **argv, int filecount);

To actually read data, we’ll use a new varread instruction, installed by the parser when we see a read expression. That machine instruction will use the only other function in the inputfiles module: read_double().

/**
 * Returns true if a double value could be read from the runtime
 * input files, false otherwise. `dest` will be set to the value read,
 * if any, or zero.
 *
 * If input data exists but is in an invalid format, causes an
 * execution error.
 */
bool read_double(double *dest);

Step 1: User-Input Layer

The user input layer of hoc is built around a set of zero or more input files, specified on the command line. Any one of these files may be stdin, which is specified by the filename -.

As clients use the read_double function to read data, internally, the input layer reads from the the “current inputfile”. Whenever an EOF is read, the layer transparently switches to the next input file and restarts the read, so that the caller is unaware.

State

Since the user specified a list of input files on the command line, most of our state revolves around pointers into the filenames array. We also need a FILE* for the current input file.

static FILE  *curr_inputfile;  // the FILE* we're reading from
static char **next_filename;   // next filename to read
static char **end_namep;       // represents "no more files"

Initialization

Our inputfiles module must have its global state initialized before it can be used; our initialization function properly sets curr_inputfile and curr_namep.

void init_inputfiles(char **filenames, int filecount) {
  curr_inputfile = NULL;
  next_filename = filenames;
  end_namep = filenames + filecount;
  next_inputfile();  // ensures curr_inputfile is either valid or NULL
}

At the beginning of main, we call init_inputfiles() with any elements of theargvarray after the program name, assuming all command-line arguments are input files. This ensures that all calls to our input functions have a validcurr_inputfile, and if it'sNULL`, we are out of input.

  int main(int argc, char *argv[]) {
    program_name = argv[0];
+   init_inputfiles(argv + 1, argc-1);
    install_hoc_builtins();
    ...

Switching input files

We call next_inputfile to switch to the next input file whenever we read an EOF. It returns true if another input file is found, or false if all specified inputs are exhausted.

/**
 * Change curr_inputfile to point to the next input file, if
 * any. Closes any existing input file (unless that file points to
 * stdin).
 *
 * Returns true if there is more input to read; false otherwise.
 */
static bool next_inputfile(void) {
  if (curr_inputfile != NULL && curr_inputfile != stdin) {
    fclose(curr_inputfile);
  }
  curr_inputfile = NULL;

  do {
    if (next_filename == end_namep) {
      return false;
    }

    // sync curr_inputfile with curr_namep
    if (strcmp(*next_filename, "-") == 0) {
      curr_inputfile = stdin;
    } else {
      curr_inputfile = fopen(*next_filename, "r");
      if (curr_inputfile == NULL) {
        warning("Could not open input filename: '%s'", *next_filename);
      }
    }
    next_filename += 1;
  } while (curr_inputfile == NULL);

  return true;
}

Reading Literals

Finally, the read_double function is implemented to hide the list of inputs from callers, and instead handles EOF conditions itself.

bool read_double(double *dest) {
  // curr_inputfile is NULL when all input is exhausted
  if (curr_inputfile == NULL) {
    warning("Cannot read input data - No input files remaining");
    return false;
  }

  while (true) {
    switch (fscanf(curr_inputfile, "%lf", dest)) {
      case EOF:
        if (!next_inputfile()) {
          return false;
        }
        break;  // otherwise try again
      case 0:
        exec_error("Could not read double from '%s' - invalid data format",
                   *curr_namep);
      default:
        return true;
    }
  }
}

Step 2: Language Changes: The read expression

After adding a read keyword to builtins.c, we can add a final expression production for our new syntax: read(destVariable). The varread instruction we install has two words; the second is the destination variable.

  expr:           NUMBER
...
          |       assign
          |       call
+         |       READ_KW '(' VAR ')'
+                 {
+                     $$ = install_instruction(inst_varread);
+                     install_ref($3);
+                 }

Step 3: Machine Implementation

Our final instruction for hoc6 is varread, which uses the read_double interface to assign a variable value and push a success boolean onto the stack.

int inst_varread(void) {
  Symbol *dest = (pc++)->symbol;
  bool    success = read_double(&dest->data.val);
  stack_push(dat(success));
  if (!success) {
    dest->data.val = 0;
  }
  dest->type = VAR;
  return 0;
}

What’s Next

There are a huge number of opportunities to explore in hoc at this point! Naming just a few:

• Scoped variables
• String, array, and integer variable types
• Named parameters to subroutines
• Debugging support
• Improved editing support (line editing, etc.)

Hopefully you’re as excited as I was upon reaching the end of hoc6 to keep exploring– there is so much low hanging fruit! Can you build a language you’d actually want to use in a real task?

If there’s enough interest, I’ll add more details to the adhoc source code where some of these ideas are explored. Please feel free to drop me a line; feedback is always welcome!