[Joker_vD]

Yes, and you can also just use parallel arrays of ints (or of constant-sized arrays of ints), because who needs structs with fields, really?

    #define  NUM  0
    #define  BOOL 1
    #define  VAR  2
    #define  IF   3
    #define  LAM  4
    #define  APP  5

    int  nodes[MAX_NODES][4];
    int  next_node;

    int mkIf(int condExp, int thenExp, int elseExp) {
        assert((condExp < next_node) && (thenExp < next_node) && (elseExp < next_node));
        nodes[next_node][0] = IF;
        nodes[next_node][1] = condExp;
        nodes[next_node][2] = thenExp; 
        nodes[next_node][3] = elseExp;
        return next_node++;
    }

Need additional data to stick to a node? Declare another array of MAX_NODES length and put it there! That's how Real Programmers wrote compilers in the seventies because real programmers write FORTRAN.

[3cats-in-a-coat]

I'm unsure what's the point of your satire. Sidecars are not just something people did in the 70s, it's a pervasive pattern seen in databases (there known as columnar storage), distributed services, gaming engines (like Entity Component System architectures) and so on.

What are you even making fun of?

[Joker_vD]

That's not a satire. That's how people used to write code. Heck, I wrote a toy multi-pass compiler exactly like that in a B-like toy language that only had ints and arrays of (arrays of...) ints for data.

But that's incredibly old-fashioned; I am making fun of your "we write compilers like it's the 90s, and it's not the 90s" because you propose the technique from the early 70s. It's not the 70s.

[3cats-in-a-coat]

Well, if I must clarify my statement, my point was we sometimes write compilers like we're restricted by 90s limitations and understandings, and we aren't. I'm not rejecting something, simply because it was invented in the 90s, or 80s or 70s (or even before computers existed). Naturally, the way we run systems is as old as the world. We just have faster, smaller and more complicated systems now.