Re: relative complement?

On 18/03/2011 4:36 PM, Erwin wrote:
> On 18 mrt, 22:44, paul c<anonym..._at_not-for-mail.invalid> wrote:
>
>> Given their chosen languages I don't fault
>> them, it's just that I don't think all possible languages need those
>> concepts, eg., a functional language might depend on side-effects for
>> recording relations.
>
> I suspect your "side-effects" are what Date calls "cheating" when it
> comes to functional languages and how they do I/O.
>
> At any rate, every single bone in my programmer's body tells me side-
> effects are bad news. They are the pest AND the cholera. They are
> variables existing (AND being updated !!!!) without having been
> declared. Therefore, they are about not knowing the full results of
> the execution of your program. And "not knowing the full and complete
> result" is nothing more than, in a mathematical sense, not being truly
> functional to begin with !!! You can call me biased if you want to.
> ...

I think you're no more biased than Date is when he advocates multiple assignment. I can see that you need some language feature like that if your chosen environment includes the ability to make relation values persistent on the fly.

But the same effects that MA allows could theoretically be achieved by referring to before and after values of some updated relvar R, not through a relvar name but through two different named (immutable) values, say R and R2. In other words, within some 'context', there is only one value of R and one of R2. Not sure, but I'm guessing that R and R2 would be what Date calls pseudo-variables, I haven't paid much attention to what he's written about pseudo-variables. The 'context' would be one of multiple possible situations.

In conventional languages the above might seem absurdly ponderous, eg., people might conclude that every program text can be executed only once. But I'd say it depends on context. For example, I don't see why a transaction couldn't be defined in terms that Jim Gray never suggested (AFAIK). The transaction might depend on a starting value of R which remains constant until the transaction has taken effect along with values R2 which might be derived from R and R3 which might be derived from R2 but which are both constant in the context of the transaction. The context of the transaction exists only when the transaction is not in effect. When all the assertion(s) of the transaction are in effect, the 'side-effect' is that R2 and R3 are not referenceable but R has the value that R3 had when the transaction was in effect.

I admit that one could say this is the same kind of effect that multiple assignment has, just with slightly different clothing and maybe Date is justified to call it 'cheating'. It's just personal with me, I'd rather separate the concept from the immediate language which I think is a neater way to get along and also I've long had a wish to write programs the same way I was taught to write arithmetic algebra expressions as a child and read them back so simply or test them with a truth table. Perhaps that's an infantile wish that has only to do with my own inability to be confident about keeping track of variables and statement order. (Or maybe I'm just in my second childhood - if so, bring on the third one!) Anyway, I do think that in the big scheme of things, simpler and more predictable programs are much more important than most db issues and the way to those involves minimizing the concepts that one must be aware when coding. Received on Sat Mar 19 2011 - 01:30:39 CET