4 ms·
It has to though. X = Y; // what should change?
by sjwright 6y ago
It has to though.
X = Y; // what should change?
- edejong 6y agoX_{t+1} = Y_t Doesn’t have to.
- dragonwriter 6y agoYou say nothing has to change, but what you write to support it is explicitly that X changes based on Y, since you are just making the time sequence explicit in the code instead of implicit in the operator syntax.
- fernmyth 6y agoIn a declarative language, nothing.
- pron 6y agoBut computation has an intrinsic directionality. If you have two expressions a, and b, and you want to unify them in a declarative language as a = b, then having an unknown subterm in one or the other can make the computation have a completely different complexity, making one direction easy and the other intractable. The P vs. NP problem is a famous question exactly about this directionality. Here's a simple example (in a declarative language that allows non-terminating computation; in a total language similar examples can be given, except "impossible" means intractable rather than non-computable, which, for all intents and purposes is the same): X = terminates?(P(1)) If X is known then finding a P is easy; if vice-versa, finding X is possibly impossible.
- phendrenad2 6y agoOh, I meant in the special case of something that can only be an r-value on the left such, such as a constant or function result. But yeah, it could still confuse newbies, because the problem is not understand that it's procedural.
- dragonwriter 6y agoWhichever isn't currently bound to a concrete value, or neither (except that they become bound to each other) if neither is; if both are, it's an error should occur, since they cannot be unified.