It's too bad it took so long for Pd Vanilla to get simple, long-requested features like fetching abstraction args. If it had, someone could have designed a simple, standard abstraction to parse comma-delimited named args (and put a matching one in the public API).
So here's what I'm getting at-- when you start messing around with things like named args, you quickly start to see big productivity improvements that you can build into an interface if the environment gives you the tooling to quickly iterate over those improvements.
So [for++ 1 8 0 2]
is an improvement over [until]
in some ways, and [for++ start 1, end 8, step 2]
is a more readable improvement on both.
But really, if we're setting up state to loop, and our system has automatic newlines on semicolons, why not just add the calculations directly in the body of the object?
[for++ start 1, end 8, step 2;
do some stuff;
more stuff here;
etc.]`
And if we're in the scope of a box, why not use a named arg to access the iterator variable when setting both the loop and the calculations?
[for++ i 1, i < 8, i + 2;
do some stuff with i here;
i * 2 * 3.14;
etc.]`
Here's an example called "dup":
Unfortunately, the tooling in Pd keeps this from being a more serious effort:
- Very difficult to parse tokens in Pd. So I have to just depend on the user to remember to surround "i" with spaces, and I can't easily report an error in that case.
- Even if I could report an error, that error can't prevent the object from successfully creating. But if the user typed in erroneous syntax, that's exactly what should happen.
- There's just no sensible way to leverage functionality from other classes, like I'm doing with expr here. You have to dynamically instantiate full canvases of objects. That just doesn't scale and tends to be very difficult to debug.
Edit:
- Iterating over lists of arbitrary atoms is extremely finicky in Pd. For just one example,
[route]
doesn't play well with lists-- you have to trim the list in order to route by the first element of the list, but the moment you do that you risk badly formed messages like "float boat etc." and "symbol 1 foo"
In terms of teaching paradigms for Pd, sticking to lists of float atoms makes the most sense. Students can leverage patterns of manipulating floats with impunity. While they can send around lists mixed with symbols and floats, manipulating these lists in any but trivial ways will quickly hit a wall with problems like these.