Shay Lewis

Some thoughts on `assert`: - Would it be able to play nice with prop-level connectives? I suppose it could just distribute over boolean connectives, making them act on props instead....

I guess what had me looking down that path was thinking of `assert` as more a macro or tactic than a function: it operates on the syntax of a boolean...

> Alternatively, perhaps we could just write forall x, y. ... and try a bit harder to infer that the type of x and y must be a. I don't...

This sounds like it results in each `watch` call traversing (to pass through any `Computed`s and find all the `State`s) and creating (to connect the watcher to the states) an...

The watched/unwatched transition happens the first (last) time they're added to (removed from) _any_ Watcher -- so I think the question is more "how often are you going to watch...

> This was the design intention. Signals can't be read during the notification phase because there is no guarantee the graph is in a consistent state - some Computeds might...

@robbiespeed Could you bring some of this discussion of cached vs. uncached computeds to https://github.com/tc39/proposal-signals/issues/151 if it's the same topic, and start a new issue for the error-vs-value suggestions if...

This is closely related to the "classic" functional reactive programming stuff, which is basically "circuits with a `delay` operator". It's a pretty clean/principled way to introduce state/history into a reactive...

It's implementable for lazy computeds but it's no longer very well-behaved. A lazy computed only runs when someone reads it, so its previous value isn't determined solely by the history...

The annoying thing here is it's still possible to write well-behaved lazy computeds that make some use of history, as long as the history doesn't affect their value (as defined...