[sc34wg3] TMQL: function-invocation and parameters

Robert Barta rho at devc.at
Mon Feb 23 14:22:31 EST 2009


On Fri, Dec 05, 2008 at 01:22:36PM +0100, Lars Heuer wrote:

> TMQL defines a function invocation as follows (abbreviated):
> 
>     [36] function-invocation ::= item-reference parameters
>     [37] parameters ::= tuple-expression
>                       | named-parameters
> 
> and tuple-expression is defined as:
> 
>     [24] tuple-expression ::= '(' value-expression ('asc'|'desc')?
>                                  (',' value-expression('asc'|'desc')?)*
>                               ')'

Correct.

> I wonder why 'asc' / 'desc' should be allowed for function
> invocations and I have the suspicion that "parameters" references
> "tuple-expression" to save a grammar production.

Even if your suspicion were correct, that would be a legitimate move,
IMHO. Creating special rules for special cases in special situations
carries the special risk of creating "holes" in the language. Happens
easier than the language creator may be aware of.

> If my suspicion is correct I propose to add an explicit "parameters"
> grammar rule which does not reference "tuple-expression". If my
> suspicion is not correct and the reference to "tuple-expression" is
> not a cheap trick ;) I like to know why a tuple expression is
> needed.

What may appear as a cheap trick actually tries to do something
extremely clever! :-) Consider this:

     myfancyfunction ( // person desc )

First all person topics will be extracted from the context map.  Then
these topics are sorted in descending order (whatever that may
mean). All this creates one ordered tuple sequence.

Then it says in 4.12.1, that if that tuple sequence is pushed into a
function each of the tuples will be used as ONE parameter set for ONE
invocation.

What it means is that if a sequence is ordered (maybe because of
nested query), that ordering is not ruined by a function invocation at
a higher level. If you nest query expressions, that is exactly what
you would hope for.

\rho


More information about the sc34wg3 mailing list