Re: A different definition of MINUS, Part 3

On 20 déc, 15:36, paul c <toledobythe..._at_oohay.ac> wrote:
> 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.
There are a lot of problems related to deriving a language definition directly from traditional algebra, one of them being determining a semantics that maps to RL traditional formalism in an exhaustive fashion, while remaining effective to be expressed semantically by a programmer. Since defining a language does not answer the same problem than establishing a theorem, it is difficult for me to imagine they could both be similar solutions.

More reasonnably, I would assume that a computing model is to be derived first (such model would be defined according to fundamental and core RL principles). Then a subsequent language definition could naturally be derived from the computing model.

There are many advantages to that approach, first being that independence between the two layers allows verification of potential contradictions between the fundamental concept and potentially candidate computing model for implementation. Since they both are based on common basic axiomatic, they should not contradict. And if they do , that contradiction may just prove interesting to study.

As an analogy, I would say that the relation between relational algebra and a relational computing model is comparable to the relationship between mathematics and physics. Both respect same fundamentals but do not respond to the same obligations. Physics has its own set of constraints: observation, extrapolation. But physics is not mere extension of math. It uses mathematical tools selectively and is not exclusively driven by it. Physics has forced on many instances the reformulation of equations that proved inconsistent with observation.

> 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.
A relvar is a construct that may be practical in determining a theorem but be unpractical in representing effective and pertinent semantics. For instance, I do believe that a semantic JOIN represented *as-is* is simply a poor unimaginative way to implement the relational JOIN. I believe that subtyping on the other hand takes away the need for the semantic JOIN while allowing an implicit JOIN operation. I do also believe that such dissociation is becoming urgent as a lot has been written about RM but too little about a computing model that could allow to implement core relational concepts.

Regards...
[Snipped] Received on Sat Dec 20 2008 - 21:22:02 CET