(2) SQL includes numerous statements whose sole function is to have side effects - not to describe the result of the total computation. So it is not declarative.
Hmm, I am not sure that I am clear on what you mean here. If you mean "any DML", then I would disagree that their effects were "side-effects" rather than intended effects, or that any intended effect other than returning computation is necessarily non-declarative. In a larger scope with temporal dependence, that's true, but on it's own, I see nothing that automatically makes it non-declarative.
If you were referring to something else, then I probably agree, but I'd like an example to be sure. 🙂
Well, if I had been referring only to things like variable assignment it wouldn't really have been worth saying. But there are ways in which one can use DML in a horribly non-declarative manner, in fact in a psitively evil manner (which is certainly not how its inventors ever intended it to be used. take this chunk of code:
UPDATE T1 set x= some expresion
from Table1 T1, Table2 T2,....
where some condition
SELECT some expression using T1.x, U1.y, U2.z ... from Table1 T1, AnotherTable U1, YetAnother U2....
where some other condition
The update of T1 to provide values to be used in the SELECT statement but NOT to alter the state of the database is clearly an intentionally non-declarative use of side effects. It matters one jot not that I would want to shoot any programmer who wrote such a thing, the point is that the language clearly allows it.