[sc34wg3] Comments on N448

[Robert Barta]

On Tue, Nov 25, 2003 at 09:42:09PM +0100, Lars Marius Garshol wrote:
> 
> Hello Kato-san, and welcome! I'm glad to see that you are now actively
> involved in this work.

Welcome also from downunder!

> * Hiroyuki KATO
> | 
> | * In general, high level query languages must be declarative same as
> | SQL or XQuery is. So, add "TMQL must be declarative and must be
> | independent of any particular evaluation strtegy." to
> | 4. Requirements for the Language or a suitable section.
> 
> I think you are right about this, and in fact we used to have half of
> that requirement in the document, but we seem to have lost it.

I think we were rather reluctant to make this explicit while most of
us favour a declarative approach. I am still reluctant to commit
myself as do not fully grasp the implications.

> I suggest we add this as item 4 in section 4.1, unless someone is
> against it. Robert, what do you think?

If we say that "TMQL should be declarative", then we probably mean
that "TMQL has a declarative semantics" (it could also have another one).
Then it would fit maybe more into 3.4 Semantics.

> | "Declarative" means that answers are specified by properties they
> | satisfy, with no refernce to an algorithm for producing them[AHV95].
> 
> The standard may define the query results through the application of a
> particular algorithm, but I agree that it shouldn't *require* that
> algorithm to be used. I think without such a specification it may be
> difficult to specify some aspects of how TMQL language features
> interact.

I completely agree. For many purposes a declarative semantics is
easier to specify, for others a (state-oriented) algorithm is better.
Why limit ourselves?

For instance, to define how an application should react in case of
exceptions is easy to do via an algorithm. Using declarative semantics
you would have to move into category theory and use monads (Phil
Wadler rulez :-).

> | * TMQL should support grouping and aggregations functionality.
> 
> Again I think you are right, and this is a requirement that just
> slipped through the cracks, but really ought to have been in there.
> I suggest we add this to section 4.3 as item 7.

In my version here 4.3 already has an item 7 (using LIMIT). But, yes,
aggregation should be here, although not necessarily as ugly as in SQL ;-)

> | "4.1 Functionality" is briefy described. So, the granuality of
> | functionality is different from each of three functionality in 4.1,
> | but both AsTMa? and tolog don't mention this, as far as I know.
> 
> I'm not sure what you mean by this. tolog has aggregates, but not yet
> any grouping support. I don't know about AsTMa? 

Section 4.1 can be so short as we rely on the use cases to
(indirectly) specify the functionalities.

AsTMa? is making heavy use of the constraint language AsTMa!. Most
declarative semantics will have to be there. This describes the
functionality itself; AsTMa? is "only" an output generating wrapper
around AsTMa!

\rho