[3cats-in-a-coat]

Restrictive static typing creates a lot of problems that wouldn't exist... if you didn't use restrictive static typing. Maybe because my language designs are toys I use in my projects (for now), but everything is nested heterogenous sparse sequences, so it's a list, but also a map, and I can attach any associative keys to it without breaking the pattern match on the rest of it, and I'm never out of place to add information should I need it.

I think the problem is we write compilers like it's the 90s, and it's not the 90s.

But also it's full of data structure solutions to this even for static types: give nodes a simple autoincrementing id (if your language has no object maps), then put any extra information in a sidecar if you want. Think relations and joins. It's easy.

[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.