

Elm – functional reactive language for interactive applications - Lenad
http://elm-lang.org/

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

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

------
mattdesl
Curious 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](http://elm-
lang.org/edit/examples/Intermediate/Mario.elm)

Otherwise it looks great. :)

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

