Something I was thinking about yesterday, while adding to my [text sequence]-based abstractions:
[text sequence] is a stateful object, in that the result of [step( depends on the previous state.
What if you need the result to be handled differently in different cases?
Specifically, I'm rejiggering the data so that it outputs the time delta to the next event alongside the data list, rather than the time delta from the previous event. As a step sequencer, in pseudocode, it looks like this:
coroutine t = text sequence blah blah; list = t.next; #time ... data = list; // [list split 1] time --> time outlet; // withhold data now wait for bang; while list = t.next; list isn't empty do #time ... data2 = list; time --> time outlet; data --> data outlet; data = data2; wait for bang; loop; end
So there's an "initializer" handling of the [text sequence] result, and then a "normal" handling within the loop.
For stateless operations like [+ 1], you can just replicate the operator for the different contexts. But because [text sequence] is stateful, you can't do that.
I could actually think of a nice, clean solution for numeric results -- I'm OK with this as it would scale up to any number of references:
But [value] can hold only a single number (why? wouldn't the equivalent of a 'variant' type be useful?), and [text] is dealing with lists.
I ended up using the [list prepend] --> [route 0 1] trick -- fair enough as the above routine uses the sequence in only two places. It might not scale when things get more complicated (for instance, in https://github.com/jamshark70/ddwChucklib-livecode/blob/master/parsenodes.sc I'm passing a stateful string iterator through dozens of functions, haven't counted them but I guess it's easily 50 or 60 places -- from a computer science perspective, a parser is not an exotic use case -- quite common really -- [route 0 1 2 3 4 5 6 7 8 9 10 11 12] oh, I give up already ).
Wondering if there are other options. It would be really nice if graphical patchers had a concept of a shared object reference, replicating the 't' variable in the pseudocode, but I guess that won't happen soon.