Thank you, Christian, this was important information! From now on I will take
precautions I have been getting away without for > 10 years, but it is no
problem.
Kind regards,Hans-Jürgen
PS: As the famous sports reporter Ernst Huberty once said, when speaking of the
double pass trick performed by Franz Beckenbauer and Gerd Müller match in match
out, citing Confucius: when you have done something for five years, consider
changing it; when you have done it for 10 years - change it. Am Sonntag, 6.
April 2025 um 17:07:20 MESZ hat Christian Grün <[email protected]>
Folgendes geschrieben:
Hi Hans-Jürgen,
The XQuery specification does not provide rules for compiling
nondeterministic/side-effecting expressions. Things are getting even trickier
if the code is hidden in the body of a function item. While we try to preserve
such code, it’s generally risky to bind variables that will never be referenced
(and to return an empty sequence), and it’s safer to invoke such functions in
sequences:
let $fnCopy := function($term) {trace('yes', 'within fnCopy: ')}
return (
trace('before call fnCopy'),
$fnCopy('yogi'),
trace('after call fnCopy')
)
A little hack is to prefix a function call with the (BaseX-specific)
'nondeterministic' keyword (it works similar to the 'updating' keyword for XQUF
expressions):
let $result := nondeterministic $fnCopy('yogi')
Hope this helps,Christian
On Sun, Apr 6, 2025 at 3:56 PM Hans-Juergen Rennau <[email protected]> wrote:
Dear BaseX people,
I observe a behaviour which appears to me not desirable, although it is,
strictly speaking, correct. Please consider this code:
let $fnCopy := function($term) {trace('yes', 'within fnCopy: ')} let
$_DEBUG := trace('before call fnCopy') let $result := $fnCopy('yogi') (:
let $_DEBUG := if ($result eq 'NEVER') then error() else () :) let $_DEBUG
:= trace('after call fnCopy') return ()
As long as the commented out clause is not activated, the function is *not*
executed. It is strictly speaking correct behaviour: the processor may optimize
and skip the call of $fnCopy, as it does not contribute to the value of the
containing FLWOR expression.
However, when using functions with side-effects (as file:write()), it is of
course necessary to be sure that the call is executed. Contrary to other
processors, according to my experience BaseX has never skipped let clauses for
reasons of optimization, and in many years of usage I have again and again
highly appreciated this behaviour.
The skipping behaviour is new to me. Is it so that BaseX has changed its policy
concerning let clauses not contributing to the FLWOR result? It would be very
important to know, because the execution of functions with side effects is
everyday practice.
Kind regards,Hans-Jürgen
