Hello Jean, If I got you right, you basically want to have a signal that changes its value by a predetermined transform function whenever there is an edge detected on a bool signal. In that case, it would be easier to define it in terms of transfer: accumIf :: a -> (a -> a) -> Signal Bool -> SignalMonad (Signal a) accumIf v0 f b = transfer v0 g b where g _dt c x0 = if c then f x0 else x0 event :: a -> Signal Bool -> (a -> a) -> SignalMonad (Signal a) event v0 b f = accumIf v0 f =<< edge b I even factored out the edge functionality. Of course you also have to pass playerX0 to this function as is, without the pure wrapping. Also, your flat function is practically equivalent to (return . pure), why did you define it using transfer? Another thing to note is that you might want to define playerX as an integral of a velocity derived from lpress and rpress, so you wouldn't need to press and release the buttons repeatedly, and the speed would be the same regardless of sampling rate, since integral takes the time step into account.

but I still can't answer my first one (couldn't this function -or its improvement- be part of the library ?) Sure, anything is possible. Elerea is a new library, and it deliberately exposes only some low-level constructs. In particular transfer, which basically lets you fall back on pure state transformer functions. My idea was that as more and more code is written in it, we can extract recurring patterns and add them to the library. But at the moment it is not clear what the useful patterns are, and I'd rather not start guessing and littering the library with useless combinators in advance.

For instance, the accumIf function is a conditional version of stateful, and it might be generally useful. Whether it's the best name, that's another question. Gergely -- http://www.fastmail.fm - The professional email service