March 5, 2010 at 8:43 am
RBarryYoung (3/4/2010)
Tom.Thomson (3/4/2010)
(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:
begin TRAN
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
rollback TRAN
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.
Tom
March 5, 2010 at 12:41 pm
RBarryYoung (3/4/2010)
In general, I think that <language> "Is A" <language-type> is just too strong a phrase for any language in real-world use. Maybe something like "Is A Type Of", or "Has The Qualities Of" would be better.
I agree, that is certainbly true in general. There are exceptions - I think everone would agree that Dartmouth Basic was procedural, and that Hope+ (and Hope and SASL) were purely functional, and Prolog without cut was purely deductive - but not many.
Tom
March 5, 2010 at 1:37 pm
RBarryYoung (3/4/2010)
Not only can you write procedurally in SQL, but you must and indeed, SQL must be designed not only to allow it, but to require it. Why? One word: Transactions. (OK, yes, there are other reasons, but transactions are the big one and there's no getting away from them). The essence of the problem is in the very definition of a transaction, an externally atomic change of the data-state of the database.So why is that a problem? (heh, here's where we get the boards really heated up...), because Relational Theory as formulated by Codd, has no such thing as "state change". Yep, I know, some wit is going to say "but didn't Gray write papers on Transactions in Relational Theory back in the 70's and 80's?" He sure did, but the problem with that is that they cannot be formally integrated into Relational Theory as Codd formulated it because it breaks the central thesis and most important aspect of Relational Theory, the mapping to Predicate Logic and Set Theory.
And that is because in Predicate Logic, there is no such thing as a "change of state". In mathematical logic, Truth is unchangeable, immutable and eternal, it can never change.
Yes, you can formulate a definition of "state-change", but only by formulating an artificial definition of "state" with a temporal component mandatorily welded to it. But that's not Predicate Logic, that's a synthetic subset of Predicate Logic that loses almost all of its power and efficacy. And more importantly, that is not how Codd mapped Relational Theory to Predicate Logic.
And this all plays back into this discussion, and "Declarative" languages and why SQL (unlike Relational Theory) must have non-declarative elements. Because, AFAIK, know one has yet come with a way to express and manage temporal state-change (ie, "transactions") in a Declarative way. Now I do not accept that temporal order (or "procedure"), necessarily means "non-declarative" (at least as I define it), but so far I haven't seen or heard of any way around it.)
I agree with most of what you say, but I don't think a purely declarative language for transactions is impossible unless one wants to encapsulate multiple transactions in a single declarative expression, which is as you say impossible. I was working in roughly this area (actually on a Functional alternative to SQL) in the late 80s and early 90s. Never published anything (not because I got nowhere but massive hassle was caused by the company wanting everything patented before publication when a colleague and I decided to publish our work on deadlock detection in massively parallel database systems I didn't want to waste that much time again) but it didn't seem a terribly big problem and we did get somewhere. Basically the idea was to treat a Transaction as the basic construct, not try to hold anything larger than a transaction in pure declarative form (so have a procedural wrapper for work requiring multiple transactions - I would use Haskell's Monads for that these days if I had the chance to do that sort of research again) and allow the component expressions of a transaction - except the one that decided whether to commit or roll-back - to see only before-looks. The transaction construct would be eager in the commit/rollback decision function, and also in the column modification expressions, and lazy in everything else (and the only ordering was that implied by lazy or eager functional semantics). We used Codd's 9th rule of relational databases (although we were not relational in the Codd sense, although our database did use relational algebra) to allow us to avoid developing a separate DDL (that would eventually have come as functions encapsulating the appropriate DML functions, if we had not been overtaken by company politics and forced to move on to implementing a new massively parallel SQL). There are some very difficult questions about locking, but they can be solved quite cleanly.
Tom
March 9, 2010 at 8:20 am
What do the various published SQL standards have to say about this behaviour?
Surely, it is no more of a glitch, than say SQL being relatively lenient over implicit type conversion than C# etc.?
September 25, 2014 at 5:49 pm
Craig@Work (3/9/2010)
What do the various published SQL standards have to say about this behaviour?Surely, it is no more of a glitch, than say SQL being relatively lenient over implicit type conversion than C# etc.?
It's not even a glitch - it's in the design and, as Barry pointed out, it's essential.
Tom
Viewing 5 posts - 76 through 79 (of 79 total)
You must be logged in to reply to this topic. Login to reply