[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Sc-devel] (no subject)

Hi James and Julian,

I think there is some misunderstanding here, which is probably my fault.

The hard and fast rule is that distinct events require distinct Event objects, always and forever. The question is whether additional copies are made inside the evaluation tree. My point is to avoid making
those additional copies.

On Dec 12, 2007, at 8:20 AM, James Harkins wrote:
I would have to vote no, I'm afraid. I routinely write child patterns in Pbind that look in the partially populated event for the values of earlier child patterns - Pkey. I mean, I do this all the time. I can't stress that enough. All the time. This proposal would break every one of my compositions.


So, Pkey would not be broken at all. In fact, the capability would be somewhat enhanced as it would be possible to look back at completed events as well. (It would not be possible to look back on earlier partial events unless you explicitly
copied them.)

Hi Ron,

thanks for carrying on with this. Generally, I think it is a good idea to clarify the input - ouput relation in streams. What about streams like Pstutter etc?

what happens if, in a Pbind, one of the value streams further up the chain modify the inevent? then this change would propagate into the downstream.
Maybe this is a degenerate nodo case ...

Pstutter has to copy, because each event needs a unique Event. (Also because upstream processing could be depending on the event
being only partially specified.)