search

z0w0 / helm

A functionally reactive game engine, with headgear to protect you from the headache of game development provided.
http://helm-engine.org/
MIT License
600 stars 69 forks source link

RFC: Revamp or remove FRP.Helm.Automaton #44

Closed z0w0 closed 10 years ago

z0w0 commented 10 years ago

Elm recently completely revamped their automaton module in favor of a more consistent design around arrowized FRP. I haven't actually seen automatons get used for stuff (although they are actually useful, just you don't necessarily need them because it's quite easy to map from signal to signal). I think we should just remove it. Thoughts?

tomberek commented 10 years ago

The point of automotons are for a signal to have state. I'm not sure that removing it completely is beneficial. https://github.com/evancz/Elm/blob/master/libraries/Automaton.elm data Automaton a b = Step (a -> (Automaton a b, b))

I say keep them.

funrep commented 10 years ago

Well, you pretty much end up working with signal generators when using Elerea, which are stateful. So I can't see any point keeping them. Unless of course I've missunderstood something.

z0w0 commented 10 years ago

FYI I already removed it on master, but I'll keep this open for suggestions of alternatives. Helm's automaton API was designed directly after the original Elm automaton API and they revamped it for a reason. Seeing as we're working in the Haskell, I feel like there might be a nicer way to do stateful and composable signals based on some already existing library. And @klrr, that is correct. There are benefits to having an arrowized form of signals, though.