3 ms·
If Elm really does get an analogue of `IO`[0], it could work just like that but with the special replay sauce described in the paper. The type could have operat
by tree_of_item 12y ago
If Elm really does get an analogue of `IO`[0], it could work just like that but with the special replay sauce described in the paper. The type could have operations that read and write from "cells" and "accumulators", and the command interpreter would replay code as usual.
Elm is already considering things like `Signal (Command a) -> Signal a` to blend imperative programming with FRP; in this case, you'd have functions like `Signal (Glitch a) -> Signal a`
[0]: https://groups.google.com/forum/#!topic/elm-discuss/ALLG6GrWQHY https://groups.google.com/forum/#!topic/elm-discuss/ALLG6GrW...
- seanmcdirmid 12y agoI first did a system like this for a FRP-like system called SuperGlue back in 2007: http://lambda-the-ultimate.org/node/2149 http://lambda-the-ultimate.org/node/2149 However, I was disappointed because I couldn't use signal abstractions in the implementation of this system; instead I invented something that was the beginning of the work presented here. Once you have effects (implicit or explicit), something like Glitch will work for that system. However, it is very important to make sure effects are de-serialized syntactically (they basically need to be wrapped up in commutative monads), otherwise replay isn't well defined and you'd need to go with more of a self-adjusting computation approach that preserves partial orders.