These "signals" don't seem like FRP signals (which are time-varying values, like a "signal" to an EE but not limited to real numbers) but more like Qt signals or MVC "model has updated" notifications.
Yes, you're right. I think I read some later FRP papers that used the term "signal" instead of "behavior", and I thought that was what you were talking about. FRP "events" are kind of like the kind of signals being discussed here, but there are still big differences.
FRP "events" are kind of like the kind of signals being discussed here, but there are still big differences.
I don't think the differences are that significant, JS signals are basically `latch(frp-event-stream)`, eg. FRP events yield edge-triggered systems and JS signals yield level-triggered systems, and latches transform edge-triggered to level triggered.
I understand why people can see JS signals as FRP behaviours though, as both have defined values at all times t, but the evaluation model is more like FRP events (push-based reactivity), so I think edge vs. level triggered is the real difference, and these are interconvertible without loss of information.
IIRC, the FRP literature calls both of them "signals" as a general category, just two different types.
Comments
These "signals" don't seem like FRP signals (which are time-varying values, like a "signal" to an EE but not limited to real numbers) but more like Qt signals or MVC "model has updated" notifications.
Original FRP was "behaviours" (continuous time-varying values) and "events" (discrete events, which map to current signals).
Yes, you're right. I think I read some later FRP papers that used the term "signal" instead of "behavior", and I thought that was what you were talking about. FRP "events" are kind of like the kind of signals being discussed here, but there are still big differences.
I don't think the differences are that significant, JS signals are basically `latch(frp-event-stream)`, eg. FRP events yield edge-triggered systems and JS signals yield level-triggered systems, and latches transform edge-triggered to level triggered.
I understand why people can see JS signals as FRP behaviours though, as both have defined values at all times t, but the evaluation model is more like FRP events (push-based reactivity), so I think edge vs. level triggered is the real difference, and these are interconvertible without loss of information.
IIRC, the FRP literature calls both of them "signals" as a general category, just two different types.