If I were to tell you that I was staring at a gnarly set of problems with a major component of the software at work, a component which desperately needs improvement, and thinking... "you know, out of the tarpit is a really great description of the problem I have and the vague solution I have been gravitating towards"... what would you say to me?

Which FRP, Functional Reactive or Functional Relational?

Both actually! I think the reactive aspect is extremely important to interactive systems. And the data stores I'm considering are relational-ish in nature (e.g. tuple-database) (... well, actually despite being made of tuples it's not really a relational database. But as a primitive it could have a relational layer on top.)

Here's the predecessor paper to the FRP architecture - "AST" http://worrydream.com/refs/Backus-CanProgrammingBeLiberated.pdf

Interesting, thanks!

And to answer your OP - I think you can't do better! Which is why I'm doing it this way myself. Well, if you squint your eyes and waggle your head it looks pretty similar!

I think that's a matter of taste - you might want to implement an immutable data store that looks like event sourcing, or a mutable relational thing like a standard sql database? But the ideas of expressing domain logic as relational queries is interesting, as is the separation between input state and derived state. I think the struggles of my system really stem from not strictly distinguishing between input and derived state, so everything becomes a big mess. That's why the paper spoke so clearly to my situation.

Well an "immutable" data store is still mutable - when you add entries! So it comes back down to storing history or not, which is down to supporting elements of the system that are behind in the sequence of events and not yet caught up with subsequent changes. But after that, you don't need to store history, and if you do, then you must have a domain requirement to do so, in which case, make it explicit with a history table! The question is, how do you get to each new state? AST and my squinty-eyed interpretation of tarpit FRP tell me that you have pure domain functions or derivative relations transforming from state to new or next state. I think Clojure's DB has something like that. As for input vs derived state: well that's an arbitrary distinction, really. I mean, just have derived state as your general model, and then make some state special - inputs - and "derived from something going on elsewhere". Then outputs derive "state elsewhere" from system state. The tarpit called them feeders and observers.