Re: Onto a potential relational manipulation language

Cimode wrote:
...

>> I can't comment on the syntax because i) I don't think one can get very
>> far with a syntax without seeing quite a few examples and

For example, if I were basing my dbms on the D&D Algebra, I might refer to their "Mapping the Relational Operators" in their Formal Specifications of Tutorial D (in chapter 5 of TTM 2nd edition, I believe that is unfortunately not available online). That's not to say I'm in favour of Tutorial D, it's just an example. If I write my own engine, I'm pretty sure I'll do something along that style, if not with the exact same verbs. I'd do that before writing a BNF or similar grammar.   Here're some samples:

(quote, assuming I've made no typo's):

Projection: The Tutorial D <project>

    R { ALL BUT A}
is semantically equivalent to the A expression

    R <REMOVE> A
Join: The Tutorial D <join>

    R1 JOIN R2
is semantically equivalent to the A expression

    R1 <AND> R2

    The Tutorial D <intersect> R1 INTERSECT R2 is just that special case of R1 JOIN R2 in which R1 and R2 have the same heading, so the <AND> operator of A takes cares of INTERSECT as well.

(end quote)

To me, starting this way is much more fruitful than starting with examples of complete statements that must necessarily involve other concepts such as assignment (not saying assignment is necessary, if it were up to me I would avoid explicit assignment entirely). I say fruitful because the resulting formal spec' is so small, just a couple of pages, that one can easily memorize it. This makes it so much easier to review real snippets of code or long expressions and compare to their correct behaviour. (When I first saw the original TTM book, it took a while for it to dawn on me that the definitions had a life of their own that went beyond just their use for initial implementation.)

(You can guess from the use of the < and > delimiters that they wrap elements that show up later in the grammar.) Received on Wed Dec 10 2008 - 00:14:02 CET