Signal can be closely compared to the IO Monad in Haskell. The point of the IO Monad is to have a clear separation of pure and impure values. When a function returns a non IO value (Or Signal) it is pure, this means that no matter how many times you run that particular function with the same arguments, you will always get the same result back. Of course you can still achieve this through careful programming but people make mistakes.

So why lift? If we receive a value through IO (e.g. Mouse.x) we can't determine the value beforehand, thus it is impure. Let's say we create a function to increase Mouse.x by a certain number, it's signature would be this: Signal a -> a -> Signal a. If a function takes a Signal as argument it must return a Signal as well. So now we're writing impure functions thus losing a lot of safety. Instead we can write pure functions where we don't have to worry about outside input and still apply impure value to it through lift. I'm not writing Haskell professionally, however I try to apply this technique in my daily work with other languages. Create as many modular functions that don't interact with IO as possible, and try to limit yourself of retrieving IO values in too many different places in your code.

I personally love IO Monad / Signal, they taught me how to write better code in other languages. It might seems like a hassle at first but if you get into it you'll see their charm :)

>However, can someone please tell me why Elm needs two kinds of values?

Because not all values depend on/change with time. A euclidean distance function is the same no matter when in time it exists. But, the distance between a player and an enemy is something that changes with time. So, you'd want to lift the euclidean distance function onto a signal like 'lift2 distance playerPos enemyPos'. I don't actually program in Haskell or Elm, so I don't know if that is the correct syntax, but you get the idea.

    let p = lift2 (+) Mouse.x Mouse.y

    let p = (+) <~ Mouse.x ~ Mouse.y

    let p = do
      x <- Mouse.x
      y <- Mouse.y
      return (x + y)

Pi doesn't make much sense as a signal (a time-varying value).

>tl;dr: how does elm work?

;)

The code for the Mario demo has a signal every 1/25th of a second due to the (fps 25) function call in it.

I'm not entirely sure why its updating more on keyboard, I just started using Elm but it could be related to the demo combining fps and key events into a single pipe and reacting on it. So by hitting keys you may be emitting extra events it needs to react to.