Side effects in functions passed to operators

[cubuspl42]

Does Airstream support functions passed to transforming operators (for example, but not limited to,EventStream.map and Signal.map) to have side effects?

[raquo]

Neither Airstream nor Scala have a concept of "side effects", so we can't really disallow that*. So yes, you can do dirty things inside operator callbacks, such as reading or updating a Var. It's not encouraged, but sometimes this can actually be useful to avoid more complex observable composition.

Relatedly, Airstream has shared execution, e.g. the fn in stream.map(fn) will be executed at most once per incoming event, whereas other streaming libraries tend to execute it N times per event if the resulting stream has N observers.

*BUT: you're not allowed to throw when providing some callbacks. These are marked with Must not throw in scaladoc comments. Usually there isn't a technical reason for it, I just felt it was unnecessary at the time. Maybe I'll get to adding guards in such cases some time.

PS I'm moving these issues to discussions. Apparently this closes the original issue, but the point is to move, not to close the discussion.

[cubuspl42]

Yes, I meant the same kind of disallowing as with the throw example, I did not imply that a library can enforce that on the type system level, or anything. But I think that it's quite common for libraries/frameworks to define some contract that's only partially enforceable by the type system, I don't see any paradox here (Sodium does that, it disallows side effects in functions passed to transformation operators).

I'm asking, because side effects combined with "laziness" (as it's called in Airstream; for me "lazy" sounds like eager vs lazy expression evaluation, but here I mean "evaluating-callback-only-when-there-are-listeners") is an unpredictable combination. I was wondering if Airstream has any guarantees around it. Now I know that there's a "shared execution" guarantee, that's a start. But still, the handler will be "executed at most once per incoming event", from a perspective of stream definition, so there's no way to guarantee that effects will execute at all? Does it means that only "non-essential" effects can be put there, i.e. ones that are desired but not strictly needed?

[cubuspl42]

To be fair: I don't think that it's totally unpractical to have effects in signal / stream transformations, I just know from experience that it's very tricky in term of guarantees. That's why I'm researching how other FRP / state+streaming software authors have approached this problem.

[raquo]

But still, the handler will be "executed at most once per incoming event", from a perspective of stream definition, so there's no way to guarantee that effects will execute at all? Does it means that only "non-essential" effects can be put there, i.e. ones that are desired but not strictly needed?

Correct. But it's not about "strictly needed", rather it's about the effect being part of the desired event propagation, and not making sense outside of it. When you want to run the effect for its own good regardless of other observers, you should put it in its own observer, but that would require providing an Owner. You should only put effect execution inside the observable if you want it to piggy back on the existing lifecycle of this observable, if you want the effect to happen only when the observable has other listeners.

It's like uh, you know there's WeakRef that requires other references for the object to live, and well this is sort of like "WeakEffect", that requires the observable to have other observers in order to run. Eh, maybe I'm stretching the analogy.

Ok, I could probably have said that in less words.

[cubuspl42]

I get it. I'm still not sure when such "piggy backing" is actually practical, but you made the contract clear.