However, can someone please tell me why Elm needs two kinds of values? There are simple values and then there are "signals". I don't understand why you need to make the distinction.
If you want to apply a function to a signal, you need to use "lift". From the Elm documentation:
"The lift functions are used to apply a normal function like sqrt to a signal of values such as Mouse.x. So the expression (lift sqrt Mouse.x) evaluates to a signal in which the current value is equal to the square root of the current x-coordinate of the mouse."
Why can't you eliminate "lift" and just have all values be signals? Then "lift sqrt Mouse.x" would become "sqrt Mouse.x". (Which makes a lot more sense, if you ask me...)
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 :)
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.
If all you want is syntactic sugar, Elm has infix lift operators so:
let p = lift2 (+) Mouse.x Mouse.y
becomes: let p = (+) <~ Mouse.x ~ Mouse.y
If you don't like that, Haskell has `do` notation. If Elm also had it, you could do: let p = do
x <- Mouse.x
y <- Mouse.y
return (x + y);)
http://elm-lang.org/edit/examples/Intermediate/Mario.elm
Otherwise it looks great. :)
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.