We considered this at F2F meeting in Hursley 30 July 2014 and concluded that the original bug description is a desirable change. Michael Kay has been given an action item to come up with a proposal.

Proposal:

fold-left() should use the GSR, with the operand usage of the first argument being the type-determined usage based on the type of the second argument of the supplied function.

Consider:

fold-left($seq, 0, declare function ($n as numeric, $m as numeric) as numeric {$n+$m})

where $seq is striding and consuming.

The TDU of $m is absorption, therefore the OU of $seq is absorption, therefore fold-left is grounded and consuming. 

How do we know it's grounded? Because both $zero and $fn are grounded...

We think there's potential for going beyond this e.g when using streamable stylesheet functions or known built-in functions but it gets tricky.

Still needs further work to flesh out the detail.

Note also that whatever we do for fold-left, we can probably also do the same or similar for filter and for-each, perhaps also for-each-pair.

For filter: it should behave like filter expressions if we know the supplied function is motionless (or has operand usage inspection). We can only know this for built-in functions (or inline functions if we choose to analyse them), for example it should be possible to make the following work:

filter(/*/x, function($n) {lang('en', $n)})

filter(/*/x, lang('en', ?))

Briefly discussed during today's telcon, though it is awaiting completion of an action to produce a proposal. The question was raised as to what kind of function items would be allowed in the third argument. Only allowing built-in functions would be rather restrictive. Allowing functions that atomize their arguments should be OK (but perhaps we already allow that?). To be at all useful, we need to allow user-defined functions (e.g. inline functions) and it's not clear how we can constrain them suitably.

The WG accepted the proposal in

https://lists.w3.org/Archives/Member/w3c-xsl-wg/2014Sep/0002.html

(member-only)

For fn:filter, the rules don't quite work in the same way. By analogy with filter expressions, filter($seq, $f) has the posture and sweep of $f provided that a call on $f is motionless. We can be sure that a dynamic call on $f is motionless only if:

(a) $seq is grounded, or

(b) $f is a known built-in function such as fn:nilled#1 where the argument has inspection usage, or 

(c) $f is an inline function whose body we are prepared to analyse.

But (b) covers so few useful cases that it really isn't worth bothering, especially as these cases can always be expressed by a simple filter expression: emp[nilled()]; and (c) is going into new territory that is best left untouched for now.

Given that case (a) is already handled, I'm going to make no change for fn:filter.

The agreed changes have been applied, affecting fn:fold-left, fn:for-each, and fn:for-each-pair.