3 ms·

I'm just starting out with Elm.js so I couldn't fully understand the article. However, it seemed to argue that keeping tons of event details in memory will exha

• deadfoxygrandpa 12y ago
  There are different types of FRP implementations. In Elm terminology, monadic FRP allows the definition of a function join : Signal (Signal a) -> Signal a, which would allow you to dynamically create (and use) Signals at runtime. Now imagine you've defined a function that returns a Signal, like: clickCounter : () -> Signal Int clickCounter _ = count Mouse.clicks What happens if the runtime allows you to dynamically call this function and return separate instances of this click counter? Either the value held by the counter is dependent on when it was created, which breaks purity, or the runtime system has to keep track of every input event it's ever received, which is the cause memory usage to forever grow with time. Elm disallows the bind and join functions for Signals in favor of Applicative FRP (if you know Haskell, Elm's <~ and ~ operators correspond to the <$> and <*> operators of applicative functors in Haskell.) Other implementations get around this in other ways, such as ignoring purity. Elm's creator made this interesting presentation about different ways to resolve the issue: http://prezi.com/jqowmkidsrmy/the-taxonomy-of-frp/ http://prezi.com/jqowmkidsrmy/the-taxonomy-of-frp/