[sc34wg3] TMQL: function-invocation and parameters
heuer at semagia.com
Mon Feb 23 14:48:27 EST 2009
>> 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.
In my opinion a function invocation is different and legitimates
therefor a special rule. If I'd understand why making
is a Good Thing and why asc / desc should be allowed for functions
(see below), I may change my opinion, though. ;)
> 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
> 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.
I do not understand this. As you've mentioned, the "desc" belongs to
the path expression "//person" and is evaluated before the
tuple sequence is passed into the function. Even if we'd define
function-invocation as follows:
function-invocation ::= item-reference '(' parameters? ')'
parameters ::= value-expression (',' value-expression)*
we'd get the same result, wouldn't we? Why should the function ruin
the previously ordered tuple sequence? And if it ruins previously
ordered tuple sequence by intention, why cannot the
function invocation as currently defined in TMQL ruin the sequence by
More information about the sc34wg3