Re: Lucid statement of the MV vs RM position?

Marshall Spight wrote:
> Jon Heggland wrote:

>> 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:

So your point is that it's safe to call both things "aggregate operators", because it's always obvious from context which one we mean? I could perhaps accept that, but what benefits are there in *not* making the distinction?

> Consider: if I said "The + operator adds two numbers" and
> you said "No, you need an APPLICATION of the + operator
> to do that"-- it's sort of overdoing the specificity, don't you
> think? Even though it is "crucial" to distinguish between
> an operator and an application of that operator.

I don't accept this analogy. I'm not a mathematician, but you can define multiplication as repeated addition, right? And integrals as well, in some sense? Yet I don't think it is very prudent or useful to just talk about addition, and hope it is obvious from context that we really mean multiplication or integration.

>> 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.

I thought maybe you took for granted that aggregate operator never occur outside SUMMARIZE expressions, and that therefore there was little need to separate between them.

> But new terms where there
> are existing terms that are as good or almost as good is
> just terrible, and "summarize" falls into this latter category,
> IMHO.
> [...]
> The FP world often has a "fold" function as part of the standard
> library. You pass it a collection, an operator, and an identity value.
> I actually don't prefer this, though, because of the value of things
> you mentioned earier, such as the "group by" aspect, and the
> multiple-aggregates-at-once-easily aspect.

What existing terms *do* you prefer, then?

-- 
Jon