[1-more]

You don't expect a function that hits the network to always return a valid answer though. That function would return a Result type which has Ok and Err constructors which you match against. Here's a self contained example that explains it better than I can[0].

> if we managed to program in a "multidimensional-state paradigm", where you could call a "multidimensional f(x)" where in one dimension of the state it will always be a valid reply, and the side effects would be another f(x) that would solve the side-effects in parallel, but both functions would be intrinsically bounded to each other like in the schrodinger's cat experiment.

You're _kind of_ talking about monadic binding here, which is called the `andThen` pattern in Elm. You can see it in JS when handling promises too.

[0] https://guide.elm-lang.org/effects/http.html

[oscargrouch]

In most languages you can have more than one result or pack multiple values in a struct like object and that would simply solve this problem. Another way would be to return just the status code, knowing if it failed or succeeded and passing a closure to be called when the operations finish, either with 'ok' or 'failure' signal and the possible result.

Ok, we can do all of this now, but in this vision, you would have some sort of Ohad Rodeh btree, which would track all the states (it basically needs to be some sort of GC and handle all the state allocations).

With this btree you would be able to create branches of the whole universe of states in a memory cheap way. Once theres a possible state change a new branch is created, and once consolidated(not just one, but it might change many states of the tree) it would be passed as the "front state".

If a side-effect prevented the change in state from occurring nothing would happen as the original state would keep the same.

I know this sounds trouble and that we kind of have the tools for this, but i've noticed that we have a "fractured state" problem where we end up doing much more work that it would be not actually needed if we managed to pack it all in a ubiquitous initial signal that would get 'sliced' into other signals with transforms, but would be consolidated into one again.

Rendering got that right, with a back buffer with a bunch of intervening state that is flipped as front once its all set. If things are breaking in the back buffer, just try it again or fail the whole state tree all at once, keeping the last good state intact.

We already do this manually in code, but we manage a lot of fractured states giving we don't have the bird-eye view perspective.

If you had something managing it all, looking at diffs, etc, my intuition(maybe wrong) says that it would make a more efficient and stable program, more performant, with more memory efficiency and easier to reason about from the developer perspective.

[1-more]

> In most languages you can have more than one result or pack multiple values in a struct like object and that would simply solve this problem.

There are structs/records in like every FP language. The advantage of FP is that you can have the error code and description OR you can have the OK state value, but you can't have both in the same scope and the compiler guides you to that. And that rocks.