I'd like to know more about how Eve managed reactivity (eg 'commit vs bind' and the idea of tables that contain events). What worked well? Did later iterations/inspired projects tweak this approach? How (if at all) can lazy vs eager reactivity be managed using this approach? http://docs-next.witheve.com/v0.2/handbook/bind/

The quote sounds about right. I forget why, but I remember getting sequences of commits to work was tricky in Eve. Stepping back, first-class time is a really interesting idea that I'd like to see more systems explore.

@wtaysom yes - @ibdknox said similar comments in 2018 here: https://news.ycombinator.com/item?id=16631333

I mean making change of time more explicit: more directly observable, manipulatable, and constrainable. This can take many forms. Here's an example. Step 0: Setup Imagine a fairly conventional imperative system. We have a bunch of boxes (variables) in which we can put values. Step 1: Observable We show which values go which boxes in what order. Often systems let us check state only in the moment or keep dubious logs about what happened in the past. Forget asking about the future. Imagine lining up the boxes. We might be able to scrub forward and backward through time, or add a timeline showing what values were in each box when. Step 2: Manipulatable Good old structured programming is kind of nice on this front. Each assignment statement records how the contents of a box change. Suppose we directly manipulate the boxes in some other way, then we can record a script of the assignments made. Glue scripts together. Good, clean fun. Step 3: Constrainable Except we don't abstract cleanly from the step-to-step to composable recipes. With functions/procedures, we keep track of arguments and return values, but we don't keep track of what boxes get examined or updated. We can't easily tell if ordering of calls matters, and we cannot easily require that things always happen in a certain order.

If you try to create a fully declarative, reactive semantics, I think you eventually run into the bind/commit distinction no matter what you do. Fundamentally, it’s a question of how the lifetime of an assertion is controlled. Commit is saying the lifetime of this assertion is unconditional, whereas bind is conditioned on the other information this assertion is derived from. You’ll want both, but it’s awkward trying to make them play together.

In case the Statelog link doesn't work http://users.sdsc.edu/~ludaesch/Paper/moc98.pdf.

I think differential dataflows loops might be useful here. They allow having lexically scoped areas of ordered time, rather than having to try to mash everything into a single global timestep.

Yeah with DD, you’re bringing more imperative control to the declarative-ness so you can try to manually resolve some of the semantic issues that arise (via a combination of careful ordering and explicit branching)