This stuff is close-to-heart for me as FRP (and Elliott's work in general) greatly inspired my thinking over the years. Here are a few instances where the drive

This stuff is close-to-heart for me as FRP (and Elliott's work in general) greatly inspired my thinking over the years. Here are a few instances where the drive to be denotational in api design led to very satisfactory results. This is a massive "shameless plug" post, but I justify it as a dedication to Conal Elliott. First, a couple of old talks on the topic - - "Functional thinking" - Brings together some of the thinking I've applied in a few areas - http://sriku.org/blog/2015/08/11/talk-functional-thinking-for-fun-and-profit/ http://sriku.org/blog/2015/08/11/talk-functional-thinking-fo... . - "Beta abstraction for bottom-up theory building" - Shows how beta abstraction can be applied to systematically become denotational - http://sriku.org/blog/2016/02/06/beta-abstraction-for-bottom-up-theory-building/ http://sriku.org/blog/2016/02/06/beta-abstraction-for-bottom... Systems - - In "muvee Reveal", an automatic video production system, the styles are written in a Scheme-dialect called "muSE"[1] in which stuff needed to represent stylistic elements are built. The editing styles DSL [2] and documentation show how this stuff can be represented well removed from implementation details. (Disclaimer: I used to work for muvee, but no longer do so stuff may have changed.) In particular, video and animations were not modeled as functions of time to Image, but functions of a time interval [t,t+dt] to Image. The reasoning was that the interval information is critical to render motion blur. You could argue that the "dt" is a detail that can be passed on later at render time, but it didn't take away much from the API's simplicity. - Steller[3] - a library for declaratively composing dynamic temporal structures, useful (and used) for music and synchronized animations. - elm-anima[4] - a concept demo of structuring animations in Elm. This was pre-18 and so doesn't use subscriptions. Here, animations are conceived of as processes rather than functions over time. I've described the thinking in a post [5]. Elm fell out of favour for me as there were many APIs I needed to work with that I couldn't use it with and the portion that needed Elm was small in the systems I was working with. [1]: https://github.com/srikumarks/muSE https://github.com/srikumarks/muSE [2]: https://srikumarks.github.io/muvee-style-authoring/ https://srikumarks.github.io/muvee-style-authoring/ [3]: https://github.com/srikumarks/steller https://github.com/srikumarks/steller [4]: https://github.com/srikumarks/elm-anima https://github.com/srikumarks/elm-anima [5]: http://sriku.org/blog/2015/12/13/towards-reactive-animation-in-elm/ http://sriku.org/blog/2015/12/13/towards-reactive-animation-...