On Mon, 21 Feb 2005, Krzysztof Czaja wrote:
it does, since alpha51: 'list' (or 'bang') in the left inlet outputs an object's state, 'list' in the right inlet clears its state. Be careful with recursion, though, Pd is not that sort of a language...
I've already done some recursion in Pd, but only to see whether it would work.
The problem about it is that Pd is too much dependent on object-state instead of call-state, so it's not easy to just pile things on the call/return stack and unpile them, because a lot of critical data is stored in other locations that don't follow the call/return stack at all. So it's basically a mess.
Fortunately, this isn't too often "required". There's always one more workaround for anything, so there's always one more way to solve a problem without using recursion, but it's a pity that in Pd there is so much of a disincentive to use recursion.
(The worst offenders are actually my own externals... I've done some progress in rearranging things so that in the future it will be easy to fix the problem.)
Sometimes I may talk about data recursion vs control recursion; we're talking about the latter, as data recursion is just any kind of feedback that _doesn't_ use the call/return stack.
I remember talking to Miller (at Andrey Savitsky's show?) about a test suite for Pd, and how that could be structured. It would be cool if, from the code of a test for basic functionality of an object, a test for control-recursion (and one for data-recursion) could be automatically generated, because it would give us a list of all classes that currently support those features, although no documentation mentions those cases.
Mathieu Bouchard -=- Montréal QC Canada -=- http://artengine.ca/matju