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 christian.gruen@gmail.com 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 hrennau@yahoo.de 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