Hi Rob,

Thanks to your observations, I noticed that some equality checks in BaseX have been buggy since a fairly long time (since BaseX 10.x). This resulted in local:f1#2 and local:f2#2 being treated as identical function items, although the parameter types were different. Some future optimizations may have led to a situation where parts of your code were evaluated in a wrong way.

More specifically, if/switch branches that are not evaluated at runtime should cause no compile-time errors. Specifically, even if BaseX evaluates a switch case at compile time with the given variable values, an error should not caught immediately, but only if this branch is really evaluated later on. For example, the following code…

switch(<a/>)
case 'x' return 1 div 0
default return 'ok'

…is rewritten to the following expression (as can be seen in the info view of the GUI)…

if((<a/> = "x")) {

error(Q{http://www.w3.org/2005/xqt-errors}FOAR0001, "1 cannot be divided by zero.")

} else {

"ok"

}

In your code, I guess that the error was directly raised. But that’s wild guessing and would need further research. All I can say is that buggyDemo.xq can be evaluated with the current snapshot [1].

Hope this helps,

Christian

[1] https://files.basex.org/releases/latest/

On Tue, May 20, 2025 at 10:22 AM Rob Stapper via BaseX-Talk <basex-talk@mailman.uni-konstanz.de> wrote:

Hi Christian,

Good news, I hope. The problem with the dynamic typecasting is not as much a typecasting-issue but an issue with recognizing derived functions. The problem is that derived functions are treated as functioncalls where it shouldn't. I can remenber that once there was an issue with the parity of derived functions. It is something like that.

attached some demos:

[referentialDemo.xq] shows that dynamic and strict typing works within version-11.9

[buggyDemo.xq] shows that dynamic and strict typing fails in case of derived functions.

[workingDemo,xq] show the workaround.

Thought you would like to know what the issue is.

Rob
---------- Oorspronkelijk Bericht ----------

Van: Rob Stapper <r.stapper@lijbrandt.nl>

Aan: Christian Grün <christian.gruen@gmail.com>

Datum: 14-05-2025 18:43 CEST

Onderwerp: Re: [basex-talk] functionParameterTyping issue

>>As can be seen, case "a" can never work if $p is a string.

correct, the error triggered by the system when calling this function is part of the validation mechanisme. Once correctly validated the data wil be stored as XML and wil be garanteed to be a string (in this case). It is not a hidden dependency as such but a managed dependency.

Thanx for your time,

Rob

Op 14-05-2025 18:01 CEST schreef Christian Grün <christian.gruen@gmail.com>:

It is more like:

let $n := "b"

let $p := "test"

return switch($n)

case "a" return fn( $n, $p as map(*) ) { }( ?, $p)

case "b" return fn( $n, $p as xs:string ) { }( ?, $p)

default return ()

As can be seen, case "a" can never work if $p is a string. If there is a (hidden) dependency in the semantics in your code that $p will always be a map if $n is "a", it is something the complete cannot »guess«. In those cases, it is better to omit type declarations in your code. The reason is that the optimizer will also rewrite and simplify those parts of your code that may not be evaluated at runtime.

Hope this helps,

Christian
mvgr.

Rob Stapper
mvgr.

Rob Stapper