When your whole program is a signal network, you don’t think about whether “this specific signal” does stuff.
Conversation
OK. I really, really don't understand what you're saying, but I'm willing to believe that's because I haven't made such a pgm
1
1
Here’s an example. A button that should fetch some data from a service and display it in a label on-screen.
1
If you look at it holistically, the new label value is an output, transformed from the input which is a button press.
1
The network request has been embedded in there, but who cares? It’s just a mechanism for converting the input to output.
1
How is this unlike "I wrote a function which the button calls; it has a callback handler—don't worry about if it has effects"
1
That’s not declarative, and it’s not a transformation.
1
I can make it declarative with addTarget. I don't see why it being a transformation or not lets me stop caring about effects.
1
I’m doing a poor job explaining why, but it makes all the difference in the world. This can be seen in arrowized FRP too.
2
1
Yeah, I really, really don't see why this frees me caring about from isolating effects. But I'm interested!
1
Replying to
In arrowized FRP the effects are encoded in the types; the transformations themselves are still pure.
Replying to
Signal transformations _are_ pure. It’d be great if we had a type system capable of encoding effects.
1
1
In the arrowized FRP, the effects are performed by outside functions (e.g. runState). In your model, they're interior.
1
Show replies