Elm – functional reactive language for interactive applications
1–10 of 12 posts
Re: Elm – functional reactive language for interactive applications
#2I 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...)
Re: Elm – functional reactive language for interactive applications
#3I 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…
Pi doesn't make much sense as a signal (a time-varying value).
Re: Elm – functional reactive language for interactive applications
#4I 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…
>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.
Re: Elm – functional reactive language for interactive applications
#5I 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…
>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…
But why not make the "lifting" implicit? If you put a signal into "distance", you get a signal back.
Re: Elm – functional reactive language for interactive applications
#6Earlier quoted context omitted.
>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…
But why not make the "lifting" implicit? If you put a signal into "distance", you get a signal back.
Maybe it's just me, but that sounds very confusing.
Re: Elm – functional reactive language for interactive applications
#7I 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…
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 :)
Re: Elm – functional reactive language for interactive applications
#8Earlier quoted context omitted.
>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…
But why not make the "lifting" implicit? If you put a signal into "distance", you get a signal back.
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
let p = (+) let p = do
x Re: Elm – functional reactive language for interactive applications
#9Curious why the Mario demo is running at ~24FPS, and jumps to 45FPS when the keyboard is active. Is it throttling frames on purpose? Why can't it hit 60FPS for such a simple demo? It doesn't inspire much confidence for a language targeting interactive media.
http://elm-lang.org/edit/examples/Intermediate/Mario.elm
Otherwise it looks great. :)
Re: Elm – functional reactive language for interactive applications
#10I 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…
>tl;dr: how does elm work?
;)