[AlexanderDhoore]

I think Elm is very interesting and inspiring. The time travel debugger especially is very impressive.

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...)

[Attic]

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 :)

[davexunit]

>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.

[AlexanderDhoore]

But why not make the "lifting" implicit? If you put a signal into "distance", you get a signal back.

[pseudonom-]

That sort of unprincipled, implicit conversion is generally frowned upon (by Elm, Haskell, ML, &c.). It reduces type safety.

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)

[deadfoxygrandpa]

There was a discussion about this on the Elm mailing list: https://groups.google.com/d/topic/elm-discuss/PNtOH2CDHZo/di...

[davexunit]

Maybe it's just me, but that sounds very confusing.

[pseudonom-]

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

[vegedor]

>tl;dr: how does elm work?

;)