[Haskell-cafe] FRP : Best way to save signal history if the program needs to temporarily terminate?

[Tobias Dammers]

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 at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe