I start to want a Reader Monad stack for all the stuff I need to thread through all functions.

Yeah, these kinds of "orthogonal" things that you want to set up "on the outside" and then have affect the "inner" code (like allocators, "io" in this case, and maybe also presence/absence of GC, etc.) all seem to cry out for something like Lisp dynamic variables.

A few languages have those, and I don't miss them, because in large codebases it becomes a pain to debug.

xBase, Clipper, Perl, Tcl upvars

It depends on how you do it. XSLT 2.0 had <xsl:tunnel>, where you still had to declare them explicitly as function (well, template) parameters, just with a flag. No explicit control over levels, you just get the most recent one that someone has passed with <xsl:with-param tunnel="yes"> with the matching qualified name.

For something like Zig, it would make sense to go one step further and require them to be declared to be passed, i.e. no "tunneling" through interleaving non-Io functions. But it could still automatically match them e.g. by types, so that any argument of type Io, if marked with some keyword to indicate explicit propagation, would be automatically passed to a call that requires one.

that's basically implicit parameters, the typed, well behaved version of dynamic scoping.

Yep, I believe that's what Scala called that.

And I think we need something like this to get people off globals.

I don't think so because the result of calling an allocator is either you got memory or you don’t, while the IO here will be “it depends”

I don't get it, what's the difference between "got or don't" vs "it depends"?

The allocator’s output is only two: either you get memory or you don’t. To quote GP

> Every function with an IO interface cannot be reasoned about locally because of unexpected interactions with the io parameter input

This means with IO interface is not quiet clear what WILL happen so it “depends”