4 ms·
Couldn't the same thing be said about functions that accept allocators?
by mordnis 11mo ago
Couldn't the same thing be said about functions that accept allocators?
- metaltyphoon 11mo agoI 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”
- chotmat 11mo agoI don't get it, what's the difference between "got or don't" vs "it depends"?
- metaltyphoon 11mo agoThe 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”
- butterisgood 11mo agoI start to want a Reader Monad stack for all the stuff I need to thread through all functions.
- charlieflowers 11mo agoYeah, 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.
- pjmlp 11mo agoA 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
- int_19h 11mo agoIt 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.