I dunno about slide 39 - where calling f(x) may or may not give x a value. From a code readability standpoint, a reader of the codebase needs to be wary of every function.
I see the issue is that iff you explicitly marked it as inout, it would limit the code from a logic unification point of view. I guess this is already explored in prolog, which I have little experience with - but it feels like it would inherently limit the ability to scale a codebase to huge sizes. Maybe a combination of convention and naming would solve the problem.
It reads very like passing uninitialised variables to a function which may initialise them for you. That's one of the worst parts of imperative programming.
The distinction between bringing variables into scope and assigning them values is a strange one for a functional language, but in fairness the talk is titled beyond functional programming.
I see the issue is that iff you explicitly marked it as inout, it would limit the code from a logic unification point of view. I guess this is already explored in prolog, which I have little experience with - but it feels like it would inherently limit the ability to scale a codebase to huge sizes. Maybe a combination of convention and naming would solve the problem.