The Enchantments of Elm – writing a roguelike using FRP: Part 1 | Hacker News Reader

The Enchantments of Elm – writing a roguelike using FRP: Part 1

sridattalabs.com

36 pointssthatipamala14 comments

Nice simple demo Sridatta!

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.

Maybe I'm old, but whenever I see references to "Elm", I only think of the MUA: http://www.instinct.org/elm/

me Too.. I was thinking "Huh, why would they try that"..

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.

OpenGameArt is a great resource for free art to get programmers get by: http://opengameart.org/

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?

http://docs.elm-lang.org/library/Signal.elm

I feel like the title is woefully misleading. This is just a hello world tutorial.

Yes, it is a bit. Sorry for that. However, it is modeled after a similar series for Clojure (http://stevelosh.com/blog/2012/07/caves-of-clojure-01/) and Java (http://trystans.blogspot.com/2011/08/roguelike-tutorial-01-j...) which also do a Hello World first post. Part 2 will have a movable sprites on a map!

Considering it's part one in the series, it's not unreasonable.

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.

You should post this to http://reddit.com/r/elm too.

Reply on news.ycombinator.com