I am happy to see Elm evolving and it looks like a good framework, but there is a tendency in FRP articles to ignore prior work, as acknowledged at the end of the article:<p>&gt;  Note: Interested readers may find Lucid Synchrone interesting. Unfortunately for me, I had no idea my thesis had so much in common with synchronous programming languages at the time, but the connections are quite striking. I might argue that Elm was never about FRP.<p>My thesis was related to synchronous programming languages and articles about FRP tend to have too little to say about them, for my taste. Yes, there is a word or two in the related work, but also it looks like some wheels are being reinvented.<p>The subscriptions model reminds me of Esterel, which is imperative and uses await&#x2F;emit pairs.
In the domain of GUIs, which is related to Elm, there is ReactiveML (see &quot;ReactiveML, Ten Years Later&quot; (<a href="https:&#x2F;&#x2F;www.di.ens.fr&#x2F;~pouzet&#x2F;bib&#x2F;ppdp15.pdf)" rel="nofollow">https:&#x2F;&#x2F;www.di.ens.fr&#x2F;~pouzet&#x2F;bib&#x2F;ppdp15.pdf)</a>).
Look also at Lustre or Signal, with Signal allowing  directives to define multiple execution units: this is used to generate concurrent programs exchanging values with message passing.<p>The domain is different, though. Synchronous languages do not target web interfaces. They are about embedded systems and as such, they are mostly static. On the other hand, they  are compilable into a simple event loop with static memory usage and constant execution time. 
Maybe some of the existing research could be useful to something like Elm, even if it does not target the same problems.