Hi Phil,
On 2019-05-27 18:23, Philip Stone wrote:
Hello, I’ve run into a situation that strains my understanding of Pd’s strict determinacy – please see the attached patch of the simplest case. On my system, the stack over-flows at count 331.
I don’t understand why this happens, as the bang that re-fires the loop is not triggered until after the print. What is filling the stack, exactly?
Control flow in Pd's message system is depth-first, usually right-to-left. This means that control passes from first object to deepest object, then back up again:
in this small example
[bng] [t b b] | [print r] [print l]
the control flow stack over time is like:
[bng] [bng] [t b b] [bng] [t b b] [print r] [bng] [t b b] [bng] [t b b] [print l] [bng] [t b b] [bng]
But in your example control is not yielded back to the caller before 400 iterations, at which point the stack is filled with
... [f] [t] [spigot] [f] [t] [spigot] ....
The default stack size limit I think is 1000 objects, recent Pd let you change it - search list archives or github issues for details.
But the simplest(*) way to get recursive calls to work is often to break the recursion with a [delay 0] to start a new depth first execution chain after the current one is finished, or to refactor it to use until to iterate instead of recurse.
(*) but it can become unmaintainable in larger patches... (+) but [bang(--[until] can take a while to finish, be careful...