Re: A different definition of MINUS, Part 3

From: paul c <toledobythesea_at_oohay.ac>
Date: Sat, 20 Dec 2008 07:36:29 -0800

Cimode wrote:
...

>> The whole notion that there is some algebraic solution to the "problem" is
>> ludicrous.

> paul c and Vadim never claimed that algebric expression of the problem
> is the solution. They are only trying to rely on a formalism which
> has proven to be effective.
> ...

Yes, nobody but Brian S has suggested that the A-algebra was put forth as providing a solution to a language implementation problem. My hope is to find a language definition (WITHOUT changing any existing A-algebra operators, just to remind, there are fundamentally only three of those, some of the ones typically used are merely derivations of those three, you can say there are four if TCLOSE is included), that allows a language implementation that is not only effective for some purpose, but closed for the desired expressions of that language. In other words, one of my guesses about the problem so far is that it is the language definition that is preventing closure of certain language artifacts. So far, I have no doubt that the A-algebra is closed, and determinate, where its own defined artifacts and the results of its operators are concerned.

Within the algebra, asking what relvar values does a relation name signify is like asking what colour a relation is. The algebra's results   reduce to extension values which the language definition must then map to its own concepts, relvars with fixed headings, for one example. Same goes for any talk of the Assignment Principle within the A-algebra - search the formal definition at
http://www.dcs.warwick.ac.uk/~hugh/TTM/APPXA.pdf} and you will see that there is no mention of 'assignment' or 'principle.

As best as I can understand him, McGoveran wants to prohibit certain relvar values. While I don't argue that this will solve the language problem of 'view updating', it prevents a convenience in a dbms that I've often use, eg., copying a table to one with a different name that I can use for testing without a lot of tedious renaming (I suspect there are many other such conveniences that people find 'ergonomic'). I'll grant that there are other language or environmental devices that give me the same ability and I'll admit that some expert language designers might say that such devices ought, on principle, to involve orthogonal concepts, but I'd just as soon not have to learn such concepts if re-defining the implementation language more precisely will do instead. Received on Sat Dec 20 2008 - 16:36:29 CET

Original text of this message