Chapter 8. Operational primitives
This chapter covers
- Interfacing FRP code with the rest of your program
- Lazy values
- Transactions
- Getting a stream from a cell
- Spawning new transactional contexts
- The question of scalable addressing
Cue some soft music as we reflect that you now have a good grounding in the 10 primitives that form the conceptual core of FRP: map, merge, hold, snapshot, filter, lift, never, constant, sample, and switch. Together they create a perfect world where everything is harmonious and wonderful.
Zzzzzzzzzzzzrrrrrrrrppppppppp! (That’s the sound of ripping a record off a record player.) Certain issues dwell at the fringe of the FRP design space and don’t quite fit. This chapter is about those and how to deal with them in Sodium. Each FRP system takes its own approach to these issues, so we introduce the operational primitives.
For the entire book, you’ve been saying, “Just tell me already!” and we’ve been pretending to be Yoda from Star Wars, saying “Ready you are not! Hmmm?” Now we judge that your mind is sufficiently purified that you can learn how to send data into FRP logic and receive it out without your FRP programming being influenced by operational thinking. We’re about to teach you something that is necessary but that you should do only when necessary.