Re: A different definition of MINUS, Part 3

Cimode wrote:
...

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

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.

For example, if the language has a concept of 'relvar', I want to be able to substitute not the concept, but merely the name of the relvar in an algebraic equation (in order to compare language results to algebraic results). While the name of the relvar no doubt has other significance in a language implementation, its only significance in an algebra is to be a shorthand for some extension. This is the algebraic advantage - such language significance is stripped out of the language expressions, leaving only algebraic formulas and equations, removing the otherwise problem of having to make algebraic comparison of results and to deal with some extraneous language 'meaning' at the same time. If the concept of relvar in some language doesn't allow a one-for-one mapping of certain extensions to relvars, then I want to change the language, not the algebra.

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