It's not unreasonable for the first part to be simple, but you might be better off writing the first 2 or 3 parts, then releasing them all at once to get things rolling.
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.
A 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?
Nobody likes the tilde-arrow lift syntax! The last line could be rewritten as follows. Does anybody think it's better or worse? I tend to prefer it, though many don't like it.
main = lift2 display Window.dimensions <| lift renderState gameState
main = display <~ Window.dimensions ~ (renderState <~ gameState)
Signals exhibit the characteristics of an applicative functor, after all, so pure functions of any arity can be lifted without needing to think if you're using lift2, lift3, etc.
I really like the tilde syntax for lift. I make good use of it in my own code. From a notational point of view, I like how it reflects that the Signals are, in a sense, being piped into my functions.
I never use it in examples, but mainly because of feedback that I get. When I use them, beginners tell me they can't figure out what's going on. When I don't use them, no one tells me things! :) So for a beginner text, I think it's reasonable.
If the screenshot at the top is an indication of what your game will look like, I'd first ask Nintendo for permission to use assets from Legend of Zelda. That way you get told no right from the start and can design sprites that aren't closely protected by an external copyright holder.
15 comments
[ 3.3 ms ] story [ 43.9 ms ] threadElm 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.
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
Nobody likes the tilde-arrow lift syntax! The last line could be rewritten as follows. Does anybody think it's better or worse? I tend to prefer it, though many don't like it.
Signals exhibit the characteristics of an applicative functor, after all, so pure functions of any arity can be lifted without needing to think if you're using lift2, lift3, etc.