[PD] recursive patches?

[Krzysztof Czaja]

hi,

CK wrote:
...
 >>Is there anyway to go around the limit of not being able to load an
 >>abstraction within itself, that is, creating recursive patches?
...
 > use the [shell] object to make copies of your abstraction, do some
 > perl -p -e 's/...' or dynamically fill your new canvas by sending
 > messages to it ...

right -- recursive abstractions are prevented by checking a name
of an abstraction currently being loaded, against all the names of
parent abstractions (kept on a stack).  One dirty way to overcome
this would be to postpone instantiating, i.e. to create
abstraction instances on demand, by sending messages to a canvas.
The other way is to perform name-mangling tricks.

In case of a not too deep recursion, probably the simplest would
be to put something like [$1-quap $2 $3 $4 $5 $6 $7 $8 ...] into
1-quap.pd, then make a dummy 0-quap.pd, and type something like

for fn in {2,3,4,5,6,7,8,...}-quap.pd ; do ln -sf 1-quap.pd $fn ; done

into the shell.  Then, one can continue editing 1-quap.pd, saving
it, etc., which is not possible if the first method was chosen.

The main patch, if calling for 7 levels, would contain
[7-quap 6 5 4 3 2 1 0], etc. (wonder how many levels could be
manageable -- 100s, 1000s :)

earlier, CK wrote:
...
 > No I wonder why on earth you'd want to do that. Besides of being a
 > concept of sparkling elegance (*cough* sometimes) recursion is
 > hardly ever efficient, tough to debug and might send your whole
 > program to where all the left socks are if anything goes wrong.

[a general remark, not having anything to do with abstractions in
particular:] there are naturally recursive algorithms, quite a few
of them, and usually the best thing one can do, is to keep their
implementation recursive.  Otherwise the program is ugly, hard to
maintain (and debug!), not any better in terms of efficiency
(usually one has to somehow handle a separate stack for
per-instance data anyway).

Krzysztof