With appropriate types and behaviors and a runtime in some other language with normal functions, you could make the code you see that "looks a lot like functions" do what this language aims to do (reactive programming -- when an input changes, update the output). The key is in what these new concepts _can't_ do. They _only_ update in response to input changes. There is no part of the language that isn't intimately tied to the reactive scheduler.
Why would you want that? The paper is pretty readable, but it's (1) interesting theoretically and (2) it solves a lot of failure modes in reactive programs, such as deadlocking a single execution thread, never yielding back to the scheduler, ....
Why would you want that? The paper is pretty readable, but it's (1) interesting theoretically and (2) it solves a lot of failure modes in reactive programs, such as deadlocking a single execution thread, never yielding back to the scheduler, ....