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