Haven't done it myself yet, but toying with the idea for a project that's been in my head for a long while. As far as I gathered, you don't need to log all your signals, only the ones that go into the network from outside - everything else is by definition derived from those, unless your FRP implementation is internally impure (which, I would argue, wouldn't be deserving of the "F" in "FRP"). SQL might not be the most suitable backend, because the shape of signal data isn't a good match for the relational model. Most likely, if I were to store event occurrences in a database, I'd use a schema similar to this (postgresql): CREATE TABLE signal_occurrences ( signal_id TEXT , occurrence_timestamp INT NOT NULL , occurrence_data JSONB NOT NULL ) ...and then derive or TH-generate ToJSON/FromJSON for the event payload type. Depending on the architecture, I might have only one signal going into the FRP network, in which case I could drop the signal_id field. Other serialization formats would also work, e.g. using cereal and plain binary BLOBs; JSON has the advantage of being completely language-agnostic and having some native support in postgres. The other problem you need to tackle is how to hook into your FRP framework, and how to keep things performant when there's a long history. In the latter case, you'll probably want a "snapshot" feature as well, i.e., store not only the incoming event occurrences, but also regular snapshots of your application state, such that you always have a limited number of inputs to restore from. This, however, is a lot harder than just logging inputs and replaying them, and I don't know if any existing FRP library supports this as of yet; OTOH, IIRC I read an article a while ago describing a high-frequency trading system that worked much like this. HTH, Tobias On Wed, Jan 06, 2016 at 03:23:27AM +0000, Zans Tangle wrote:

Hi guys,

so I'm getting my head around FRP, and the theory is starting to make sense (just seen Conal Elliott's explanation of the original formulation and it was very illuminative). Overall I'm finding signals to be a really nice level of abstraction to reason about my code state.

However I'm a little bit stuck on something: lets say I want to switch off the program, but I want it to save the signal history so that I can resume where I left off when I switch it back on.

Is there a ... simple.. way to do it? Because at the moment I'm thinking of something along the lines of "build an SQL schema that matches the semantics of each FRP signal, and then build functions to translate between signal and SQL when needed".

And at this precise instant I don't really feel too excited about implementing Signal-to-SQL translation from scratch (and I'm not even completely sure what sort of SQL schema would be needed to support higher-order FRP either), so I was wondering if anything like that exists already? Or even something as simple as storing the signal history in a file and just parsing it to recover it?

Zans

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe