On 3/17/21 6:29 PM, adam johnson wrote:
and i was only saying that just because something is implemented in such-and-such way should be of no concern.
A feature not existing because of the difficulty of adding it would be one possible answer to my question, so I checked the code before coming here and it turned out to be the expected for loop.
i see. "hard to implement" would be a bad excuse, but of course not unheard of.
you still have to come up with an example where it gets so ugly it's hard to bear.
Why? I never said it is hard to bear, I said it was easy enough to work
true. but you also said:
This is easy enough [...] most of the time, but it can get ugly.
which i take as "so ugly, it's hard to bear", because if it was "ugly but no problem" you wouldn't have worried to write your mail.
It is in cleaning this patch that the question arose, but I never said I needed it, I did not request a feature.
ah sorry, i completely misunderstood your problem then.
I plainly stated that I suspected the fault was with my understanding and not pd.
ah well. i have interpreted your statement as purely rhetorical, hiding a feature request under humble understatement. most likely i misinterpreted it that way, because i often use this device myself.
Most languages give you simple ways to break out of a sequence of events, but pd seems to treat it as jumping off a cliff.
Pd is a dataflow language, rather than a controlflow language. so there's no "sequence of events" (as in: a series of instructions that are iterated via a program counter). as a Pd doesn't have a "return"
if you want to stop the "flow of data", there are programming devices that do just that: [spigot] (and its ugly sister [change]), [select] & [route] (and its ugly brother [moses]).
As I said in my first post, I am asking why, not how to do this, just trying to understand the logic of pd so I can use it better.
reasons (excuse the gibberish)
gfmdasr IOhannes