Quote from dandl on July 19, 2020, 1:06 am

That some people, after yrs of being around, still fail to see that despite how reminiscent such a spec is of algorithmics, it is *not* a prescription of an algortihm, merely a prescription of which results must be obtained, is regrettable.

The stuff wrt "computation must only be done three times" reminds me of those people who claim there's redundancy in a design "because the number three occurs more than once".  The cost of determining the optimisation must be balanced against the savings to be had from finding it.

I call out: ad hominem argument.

Mirriam-Webster:

appealing to one's prejudices, emotions, or special interests rather than to one's intellect or reason.

attacking an opponent's character rather than answering his argument.

The ad hominem argument is the last resort of the weak intellect. If you don't understand my argument, ask and I will explain it to  you.

I don't play these games.

Quote from dandl on July 19, 2020, 1:20 am

Regardless how you actually implement them, as they appear in Tutorial D the semantics are lambda expressions, and the syntax is pared-down conventional lambda expressions.

Again, I disagree. I'm discussing 'open expression' as defined in TD p3 and the notion of 'current tuple', which is not defined anywhere. As defined there an OE could indeed be implemented as an iterator over a set of tuples applied to a lambda derived from the OE, but (a) A could be implemented as B is not the same as A is B (b) there are other possible interpretations and implementations. I gave examples.

But perhaps in Rel, A is B.

 

Quote from dandl on July 19, 2020, 2:41 am

Quote from Hugh on July 18, 2020, 1:44 pm

Quote from dandl on July 17, 2020, 3:12 pm

Your revised example looks valid to me.  The second appearance of S# is an attribute reference denoting that value of that attribute in the "current tuple" of S, the relation being extended.  Such attribute references are also permitted in SUMMARIZE and WHERE.

This concept of 'current tuple' I find highly suspect. All we are supposed to know is that the attribute names actually appearing in the open expression are bound to certain values, and the result of the expression will be used for some purpose. If we have an open expression (for the S relation) such as STATUS*10, then the computation need only be done 3 times (there are only 3 unique values), so which is the 'current tuple' for these 3 occasions?

I much prefer a set-oriented view in which the entire calculation is performed simultaneously, rather than the iteration implied by 'current tuple'.

Thanks, dandl.  I completely agree, and that's why I put the ugly term in quotes.  I've never worked out a decent way of expressing the construct, apart perhaps from using the Appendix A method (via JOIN).

I like your observation concerning the number of distinct results.

Nailed it! Thanks, Hugh.

Yes indeed, what I had in mind was very much along the lines App-A, and at that level of abstraction. I think the answers are mostly there.

There are 4 places in the Extended RA where OE functionality is needed: restriction, extension, aggregation, GTC. The first two were in Codd's original paper, but only using literal values. App-A shows how this can be extended to calculated values using 'relcons'. I confess I seriously underestimated the importance of this section on my first readings, and I think the App-A paper stops just before it gets to the crux of the thing: where do relcons come from?

My answer as I set out in an earlier post is that relcons are functions. Bingo!

In mathematics, a function is a binary relation over two sets that associates to every element of the first set exactly one element of the second set.

Functions (relations/relcons) fit naturally into FOPL. They can map a set of values into a single value so they can do aggregation. They are unnamed so they cannot be recursive, but there is a straightforward method to define TC as the fixpoint of a suitably constructed FOPL series. That completes the set.

Using the same approach as App-A p12 (FORMAL DEFINITIONS) it is possible to formally define the ERA in terms of the following operators:

• REMOVE, RENAME, AND, OR, NOT as per App-A (I would prefer to call them JOIN and UNION, but that' s not important).
• An EXTEND operator, that takes a list of attribute names and a function as arguments, and returns a relation extended by one attribute (effectively a JOIN on a relcon).
• An AGGREGATE operator, that takes a list of attribute names and a function as arguments, and returns a relation with one attribute replaced by its aggregation (the function takes a list of values as its argument).
• An ETCLOSE operator, that takes 3 attribute names and a function as arguments, and returns a relation with additional tuples comprising the extended transitive closure (including the cumulative 'cost' of the path). [WHILE is a worthy alternative]
• plus DEE and DUM, as the foundation.

AFAICT this set of operators forms a complete query language to the limits of FOPL and fixpoint recursion. It can perform all SQL queries, including generalised aggregation but excluding ordered queries.

I have formal definitions for all 8 operators. Publishing them here is too hard, given the limits of the medium.

Note that it provides no type system. Functions deal in types, but these operators do not. RVAs are also part of the (separate) type system, and are opaque types to this algebra.

 

Quote from AntC on July 19, 2020, 6:06 am

Quote from Dave Voorhis on July 18, 2020, 10:14 am

Quote from dandl on July 18, 2020, 12:55 am

I can't find mention of WITH clauses on statements in DTATRM, though I admit I gave up searching through instances of 'with' because my annoying PDF viewer ignores case distinctions and punctuation. I couldn't find it in the DTATRM grammar either, though I might be staring right at it and can't see it for looking.

Adobe Acrobat does a perfectly fine job of searching.

Of searching, it did.

My complaint was an inside wry quip to myself. I had Adobe Acrobat until an update made it consume vast amounts of CPU, spool up the fans and gobble battery. I uninstalled it and unless someone convinces me that it's all better now -- and that someone probably ought to be an Adobe employee, and as I don't know anyone at Adobe... Though now that I think about it, my other half Nikki has a friend whose husband works at Adobe, and I have a former student who (last I heard) worked at Adobe, so I do know people at Adobe, but...

...I digress.

<further digression> Yes my experience with Acrobat, too. What on earth is it doing just to fire up the 'explorer view' without even opening a doco -- which then takes another several aeons? And why does it open every doco in maximum magnification, does it think I'm visually impaired? (The first thing I want to do is skim quickly through the doco to the section of current interest -- for which 100% mag is ample.) Doubtless there are config options to fix that, but what sort of UI propellor-head 'designed' that dialogue?

You might find Acrobat on iPad a lot more congenial -- that's what I use; and I can handily look at that while composing the email on my PC.

BTW you can get Acrobat search to be case sensitive, though it's again a non-obvious piece of UI design. </digression>

 

Quote from Dave Voorhis on July 19, 2020, 9:05 am

Quote from dandl on July 19, 2020, 1:20 am

Regardless how you actually implement them, as they appear in Tutorial D the semantics are lambda expressions, and the syntax is pared-down conventional lambda expressions.

Again, I disagree.

Well, I did warn that programming language comparison debates can last a full semester on one contentious assertion... :-)

I'm discussing 'open expression' as defined in TD p3 and the notion of 'current tuple', which is not defined anywhere.

"Current tuple" is informally defined on page #257 of DBE, in Chapter 14 Image Relations at the end of the Detailed Specification section.

As defined there an OE could indeed be implemented as an iterator over a set of tuples applied to a lambda derived from the OE, but (a) A could be implemented as B is not the same as A is B (b) there are other possible interpretations and implementations. I gave examples.

You're talking about implementation, I'm looking at the language semantics. The semantics of open expressions are that of syntactically-pared lambda expressions. The "current tuple" is none other than the syntactically-elided (and thus implicit) tuple parameter.

But perhaps in Rel, A is B.

In Tutorial D, A = B where A = "open expression" and B = "lambda expression."

That's what it is semantically. How you implement those semantics -- whether you pass tuples one by one to a function, or turn the expression into SQL somewhere for evaluation by an external DBMS, or something else -- is purely an implementation concern.

Quote from Hugh on July 19, 2020, 1:00 pm

Quote from Dave Voorhis on July 18, 2020, 2:59 pm

Quote from Hugh on July 18, 2020, 1:54 pm

Quote from Dave Voorhis on July 17, 2020, 5:30 pm

Quote from Hugh on July 17, 2020, 1:44 pm

Quote from Dave Voorhis on July 16, 2020, 1:31 pm

Quote from Hugh on July 16, 2020, 11:56 am

Somewhere in the plethora of recent posts in this thread Dave Voorhis said that he removed WITH support on statements in Rel when we deleted it from Tutorial D.  But that deletion took place the day I started this thread and I had previously found that Rel lacked it.  That's why I said I had been encouraged by Rel's lack of support for it.

I beg to differ. It's at the top of page 122 of my paper copy of DTATRM, and roughly the middle of page 127 in DTATRM.pdf:

• The <with> statement has been dropped and WITH expressions have been clarified.

I remember being a tad disappointed, and there might have been discussion about it on the forum at the time, but I removed it in accordance with DTATRM.

That <with> statement was merely a statement defining one or more local constants, as opposed to a WITH clause that appears as part of a statement.

The <with> statement that defined one or more local constants was what I thought you meant by "WITH clauses on statements."

I didn't know there was a WITH clause that appears as part of a statement, which would account for why I didn't implement it.

That statements with WITH clauses -- as opposed to a WITH statement -- ever existed comes as a surprise to me. It explains why the wording of the first post did seem a tad odd. I thought a WITH statement was what you meant.

Where was it defined and/or demonstrated?

I can't find mention of WITH clauses on statements in DTATRM, though I admit I gave up searching through instances of 'with' because my annoying PDF viewer ignores case distinctions and punctuation. I couldn't find it in the DTATRM grammar either, though I might be staring right at it and can't see it for looking.

Unless it was added later?

Perhaps we have been over-cautious on both counts.  If either or both of these constructs are successfully implemented (in Rel for example), I suppose we could reconsider.  I encourage you to have a go!

Support for a WITH statement that defines one or more local constants is certainly implementable. Rel used to have one. I've made a note to put it back in.

Sorry for lacking the energy to attempt an answer to your historical questions.

The effect of a standalone WITH statement can be obtained by using a WITH clause on a compound statement, clearly defining the scope of the introduced names.  I think I prefer that to a standalone WITH statement, where the scope is presumably the same as that of a local variable, and I assume that such a scope is the remaining portion of the block in which it appears (i.e., an introduced name isn't retrospectively in scope).  I suppose it could be argued that it's neat for a name not to be defined until it's really needed, but then the system should disallow a name that clashes with a name already defined in the same block.

Hugh

My plan was to implement it modeled on the current syntax and most of the semantics for WITH expressions, i.e.,

<WITH statement> ::= WITH ( <name intro commalist> ) : <statements>

Where:

<statements> ::= BEGIN ( <statements> )* END ; | <statement>

Scope of introduced names is limited to the specified <statements>. Thus, the following is valid:

WITH (a := 2 + 3, b := 4 * 5) : WRITELN a || b;

WITH (a := 2 + 3, b := 4 * 5) : WRITELN a || b;

WITH (a := 2 + 3, b := 4 * 5) : WRITELN a || b;

But

WITH (a := 2 + 3, b := 4 * 5) : WRITELN a || b;

WRITELN a || b;

WITH (a := 2 + 3, b := 4 * 5) : WRITELN a || b; WRITELN a || b;

WITH (a := 2 + 3, b := 4 * 5) : WRITELN a || b;
WRITELN a || b;

...fails because a and b are unknown in the second line.

However

WITH (a := 2 + 3, b := 4 * 5) : BEGIN

WRITELN a || b;

WRITELN a || b;

END;

WITH (a := 2 + 3, b := 4 * 5) : BEGIN WRITELN a || b; WRITELN a || b; END;

WITH (a := 2 + 3, b := 4 * 5) : BEGIN
  WRITELN a || b;
  WRITELN a || b;
END;

is valid. But the following is invalid

WITH (a := 2 + 3, b := 4 * 5) : BEGIN

WRITELN a || b;

WRITELN a || b;

END;

WRITELN a || b;

WITH (a := 2 + 3, b := 4 * 5) : BEGIN WRITELN a || b; WRITELN a || b; END; WRITELN a || b;

WITH (a := 2 + 3, b := 4 * 5) : BEGIN
  WRITELN a || b;
  WRITELN a || b;
END;
WRITELN a || b;

...because a and b are unrecognised in the 5th line.

 

Exactly as I intended.  Also:

WITH (a := 2) : BEGIN;
WITH (a := 3) : WRITELN a;
WRITELN a;
END;

should give:
3
2
Right?

Hugh

Quote from Dave Voorhis on July 19, 2020, 6:34 pm

Quote from Hugh on July 19, 2020, 1:00 pm

Quote from Dave Voorhis on July 18, 2020, 2:59 pm

Quote from Hugh on July 18, 2020, 1:54 pm

Quote from Dave Voorhis on July 17, 2020, 5:30 pm

Quote from Hugh on July 17, 2020, 1:44 pm

Quote from Dave Voorhis on July 16, 2020, 1:31 pm

Quote from Hugh on July 16, 2020, 11:56 am

Somewhere in the plethora of recent posts in this thread Dave Voorhis said that he removed WITH support on statements in Rel when we deleted it from Tutorial D.  But that deletion took place the day I started this thread and I had previously found that Rel lacked it.  That's why I said I had been encouraged by Rel's lack of support for it.

I beg to differ. It's at the top of page 122 of my paper copy of DTATRM, and roughly the middle of page 127 in DTATRM.pdf:

• The <with> statement has been dropped and WITH expressions have been clarified.

I remember being a tad disappointed, and there might have been discussion about it on the forum at the time, but I removed it in accordance with DTATRM.

That <with> statement was merely a statement defining one or more local constants, as opposed to a WITH clause that appears as part of a statement.

The <with> statement that defined one or more local constants was what I thought you meant by "WITH clauses on statements."

I didn't know there was a WITH clause that appears as part of a statement, which would account for why I didn't implement it.

That statements with WITH clauses -- as opposed to a WITH statement -- ever existed comes as a surprise to me. It explains why the wording of the first post did seem a tad odd. I thought a WITH statement was what you meant.

Where was it defined and/or demonstrated?

I can't find mention of WITH clauses on statements in DTATRM, though I admit I gave up searching through instances of 'with' because my annoying PDF viewer ignores case distinctions and punctuation. I couldn't find it in the DTATRM grammar either, though I might be staring right at it and can't see it for looking.

Unless it was added later?

Perhaps we have been over-cautious on both counts.  If either or both of these constructs are successfully implemented (in Rel for example), I suppose we could reconsider.  I encourage you to have a go!

Support for a WITH statement that defines one or more local constants is certainly implementable. Rel used to have one. I've made a note to put it back in.

Sorry for lacking the energy to attempt an answer to your historical questions.

The effect of a standalone WITH statement can be obtained by using a WITH clause on a compound statement, clearly defining the scope of the introduced names.  I think I prefer that to a standalone WITH statement, where the scope is presumably the same as that of a local variable, and I assume that such a scope is the remaining portion of the block in which it appears (i.e., an introduced name isn't retrospectively in scope).  I suppose it could be argued that it's neat for a name not to be defined until it's really needed, but then the system should disallow a name that clashes with a name already defined in the same block.

Hugh

My plan was to implement it modeled on the current syntax and most of the semantics for WITH expressions, i.e.,

<WITH statement> ::= WITH ( <name intro commalist> ) : <statements>

Where:

<statements> ::= BEGIN ( <statements> )* END ; | <statement>

Scope of introduced names is limited to the specified <statements>. Thus, the following is valid:

WITH (a := 2 + 3, b := 4 * 5) : WRITELN a || b;

WITH (a := 2 + 3, b := 4 * 5) : WRITELN a || b;

WITH (a := 2 + 3, b := 4 * 5) : WRITELN a || b;

But

WITH (a := 2 + 3, b := 4 * 5) : WRITELN a || b;

WRITELN a || b;

WITH (a := 2 + 3, b := 4 * 5) : WRITELN a || b; WRITELN a || b;

WITH (a := 2 + 3, b := 4 * 5) : WRITELN a || b;
WRITELN a || b;

...fails because a and b are unknown in the second line.

However

WITH (a := 2 + 3, b := 4 * 5) : BEGIN

WRITELN a || b;

WRITELN a || b;

END;

WITH (a := 2 + 3, b := 4 * 5) : BEGIN WRITELN a || b; WRITELN a || b; END;

WITH (a := 2 + 3, b := 4 * 5) : BEGIN
  WRITELN a || b;
  WRITELN a || b;
END;

is valid. But the following is invalid

WITH (a := 2 + 3, b := 4 * 5) : BEGIN

WRITELN a || b;

WRITELN a || b;

END;

WRITELN a || b;

WITH (a := 2 + 3, b := 4 * 5) : BEGIN WRITELN a || b; WRITELN a || b; END; WRITELN a || b;

WITH (a := 2 + 3, b := 4 * 5) : BEGIN
  WRITELN a || b;
  WRITELN a || b;
END;
WRITELN a || b;

...because a and b are unrecognised in the 5th line.

 

Exactly as I intended.  Also:

WITH (a := 2) : BEGIN;
WITH (a := 3) : WRITELN a;
WRITELN a;
END;

should give:
3
2
Right?

Hugh

Yes.

Quote from Erwin on July 19, 2020, 7:07 pm

Quote from dandl on July 19, 2020, 1:06 am

 

I call out: ad hominem argument.

Mirriam-Webster:

appealing to one's prejudices, emotions, or special interests rather than to one's intellect or reason.

attacking an opponent's character rather than answering his argument.

The ad hominem argument is the last resort of the weak intellect. If you don't understand my argument, ask and I will explain it to  you.

I don't play these games.

It's M ***E*** rriam-Webster.

Furthermore, when writing what I did, I did ***NOT*** appeal to prejudice, but instead to a ***post***judice that I formed from reading as good as every single one of the posts you wrote here.  Likewise, nor did I appeal to emotions nor to "special interests" (I have none left of the latter anymore).  Nor did I attack "character".  What I deplore in your posts is the systematic total and utter lack of precision (*).  Witness the fact that as a native speaker (which ***I*** am ***most definitely not***), you apparently cannot even manage to get the name of the dictionary spelled right.

(*) You might argue that "total and utter lack of precision" ***is*** a character trait with you and therefore, if I "attack" the former, then I also "attack" the latter.  Fair enough.  My response is that if "total and utter lack of precision" is indeed a "character" trait of yours, then maybe you should start pondering what the hell you are doing in IT.  Google "Chris Date why is it important to be precise".

Quote from dandl on July 20, 2020, 4:53 am

• An EXTEND operator, that takes a list of attribute names and a function as arguments, and returns a relation extended by one attribute (effectively a JOIN on a relcon).
• An AGGREGATE operator, that takes a list of attribute names and a function as arguments, and returns a relation with one attribute replaced by its aggregation (the function takes a list of values as its argument).
• An ETCLOSE operator, that takes 3 attribute names and a function as arguments, and returns a relation with additional tuples comprising the extended transitive closure (including the cumulative 'cost' of the path). [WHILE is a worthy alternative]

I made a mistake here, failing to distinguish between the operators of the ERA as against the language shorthands that use them. AND, OR and NOT are algebra; JOIN, SEMIJOIN, ANTIJOIN, UNION, MINUS are shorthands that use them. EXTEND, AGGREGATE/SUMMARIZE, WHERE/RESTRICT are shorthands; they depend on the RELCON/RELFUN operator. And so on.