Re: Lucid statement of the MV vs RM position?

From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Mon, 08 May 2006 22:04:24 GMT
Message-ID: <IfP7g.5181$A26.131966@ursa-nb00s0.nbnet.nb.ca>

Jon Heggland wrote:

> Marshall Spight wrote:
>

>>Jon Heggland wrote:
>>
>>>I focus on the significant difference between
>>>
>>>1. An aggregate operator
>>>2. The invocation of an aggregate operator within a SUMMARIZE operator
>>>
>>>You don't get from relation (1) to relation (2) in my post to Marshall
>>>just by using SUM. You have to use SUMMARIZE as well.
>>
>>I agree, however I consider this point so obvious as to be not
>>worth mentioning. No one bothers to distinguish carefully
>>between, say, a function literal and an application of that
>>function in speech. It's just quite clear from context.

>
> I'm not quite sure I understand your argument here; please ignore if I'm
> setting up a straw man here. I think the distinction between SUMMARIZE
> ... ADD (SUM(...) AS ...) and SUM(...) is crucial for at least two reasons:
>
> 1. A SUMMARIZE can apply more than one aggregate operator. If you use
> the name SUM for a SUMMARIZE that applies iterated addition on one
> attribute, and the name GROUP for a SUMMARIZE that applies iterated
> union on one attribute, what do you call a SUMMARIZE that applies both
> addition and union in one go? Or would you disallow such an operation,
> forcing it to be implemented as two separate aggregate operator
> invocations, followed by a join? Much pain for no gain, if you ask me.
>
> 2. If you define aggregate operators this way, you have to repeat the
> definition of the "grouping procedure" for each one. Using SUMMARIZE, it
> is factored out, and all you need to add a new aggregate operator is to
> specify the operator and the identity.
>
> Furthermore, Tutorial D's aggregate operators can also be used as
> expressions directly, i.e. not only within the context of a SUMMARIZE.
> For example, SUM(R,A) is an expression evaluating to the sum of the A
> attribute in relation R. If SUMMARIZE ... ADD (SUM(...) AS ...) is
> called "the aggregate operator SUM", what should we call SUM(R,A)? They
> are obviously not the same.

All of the above is syntax. You point to two different productions in the grammar and claim that only one can be an aggregate. However, this is not true. In both situations above, SUM is an aggregate function.

As I said previously, you focused on form while Marshall and I focused on function.

Are we talking about multiple productions in the grammar? Sure.

Does that make GROUP any less an aggregate defined on UNION? No.

Do you have a particular objection to the productions D&D chose in the grammar of their tutorial language? If so, which production(s)? How does changing the production(s) improve the language as a language? We might agree with you, and we might not.

However, I am not sure how you are going to establish a theory based argument for a minor matter of language design and syntax.

[snip] Received on Mon May 08 2006 - 17:04:24 CDT