Re: [xsl] W3C Specification of fn:filter() -- is this a bug in the document or in Saxon?

["Dimitre Novatchev dnovatchev@xxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>]

Forgot to provide the truly equivalent XPath - only implementation -- here
is one that is even non-recursive:

let $filter := function($f as function(item()) as xs:boolean, $list as
item()*) as item()*
{
  $list ! .[$f(.)]
}
  return
    $filter(function($n) {$n idiv 2 * 2 eq $n}, 1 to 10000)


On Sun, Sep 8, 2019 at 6:43 PM Dimitre Novatchev <dnovatchev@xxxxxxxxx>
wrote:

> >  You can never guarantee that two expressions are equivalent in your
> > sense, because of "errors and optimization". Any construct might raise
> > an error - in the case of this example, stack overflow if the recursion
> > gets too deep.
>
> What about tail-recursion?
>
> For years we have known recursive expressions whose tail-recursiveness is
> correctly recognized in BaseX and it provides correct evaluation regardless
> of the input size (recursion depth) but other processors fail miserably...
>
> How much value for the developers would have been provided by the
> specification if it mandated proper handling of tail-recursion!!!
>
> The value provided in a document is rather debatable when specifying
> "equivalent implementations" that blow up for reasonably long inputs
> (several thousand items isn't too high!) when other implementations could
> have been provided that demonstrate equivalence with much longer inputs
> (millions of items)
>
> Also, why in an XPath specification give "equivalent implementations" in
> two different languages neither of which is XPath?
>
> Cheers,
> Dimitre
>
> On Sun, Sep 8, 2019 at 5:54 PM Liam R. E. Quin liam@xxxxxxxxxxxxxxxx <
> xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>
>> On Mon, 2019-09-09 at 00:18 +0000, Dimitre Novatchev
>> dnovatchev@xxxxxxxxx wrote:
>> > The W3C F&O 3.1 spec (at
>> > https://www.w3.org/TR/xpath-functions-31/#func-filter ) says:
>> >
>> > Rules
>> >
>> > The effect of the function is equivalent to the following
>> [...]
>> >
>> > Because "equivalent" means the two functions must produce the same
>> > result
>> > for for all possible values in the same set of arguments,
>>
>> That is one possible definition of "equivalent" but it is not the one
>> used in the Functions and Operators document...
>>
>> You can never guarantee that two expressions are equivalent in your
>> sense, because of "errors and optimization". Any construct might raise
>> an error - in the case of this example, stack overflow if the recursion
>> gets too deep.
>>
>> Liam
>>
>> --
>> Liam Quin, https://www.delightfulcomputing.com/
>> Available for XML/Document/Information Architecture/XSLT/
>> XSL/XQuery/Web/Text Processing/A11Y training, work & consulting.
>> Carefoot Web-slave for historical images http://www.fromoldbooks.org/