99 ms·
I'm a bit skeptical if the term FRP really applies here. The usual FRP programs are written so that you first define a few primitive signals (I use the term sig
by klrr 13y ago
I'm a bit skeptical if the term FRP really applies here. The usual FRP programs are written so that you first define a few primitive signals (I use the term signal for the sake of this thread being about Elm) and then use them together with a set of combinators to build up a entire signal network that defines the program. In Elm you already have the primitives and then just step state like you would do in a FP language normally.
Elm is theoretically classic FRP with a option of a arrow interface, but the combinators for building signal networks is not provided by defult. Therefore I feel its a bit unfair to call it FRP and not having a prefix explaining that its a derivitive there of.
- johnpmayer 13y agoA few disparate points: The Elm runtime is an implementation of CFRP, where the C stands for concurrent. The primitives already exist for convenience, and can be transformed by pure functions, or new ones can be defined using the FFI. Your observation isn't new, most Elm games' signal graphs have the same shape - a bunch of input signals merged into one, the 'main' loop as a step state, and the drawing code.' In particular, which kinds of Signal combinators do you feel are lacking? http://docs.elm-lang.org/library/Signal.elm http://docs.elm-lang.org/library/Signal.elm