functionParameterTyping issue
Tuesday, 13 May 2025 · 4 messages · last reply 20 May 2025
RS
Rob Stapper13 May 2025 17:32 #
Hi Christian,
With version 11.9 I have a problem with my application. Consider the attached app. Runs in previous versions but not anymore in version 11.9. Yours thoughts on this one?
mvgr.
Rob Stapper
CG
Christian Grün13 May 2025 18:41 #
Hi Rob,
The second argument of your function call to 'local:proces' is a string, which will later be bound to '$p as map(*)'. The returned error include line/column information, which should help you to find the buggy position in the code:
Stopped at typeBug 2025-05-14.xq, 14/73:
[XPTY0004] Cannot convert xs:string to map(*): "test".
Cheers,
Christian
Quoted text · Rob Stapper · 13 lines
On Tue, May 13, 2025 at 5:33 PM Rob Stapper via BaseX-Talk < basex-talk at mailman.uni-konstanz.de> wrote: > Hi Christian, > > With version 11.9 I have a problem with my application. Consider the > attached app. Runs in previous versions but not anymore in version 11.9. > Yours thoughts on this one? > > mvgr. > > Rob Stapper > >
RS
Rob Stapper20 May 2025 10:22 #
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
Quoted text · Christian Grün · 41 lines
> ---------- Oorspronkelijk Bericht ---------- > Van: Rob Stapper <r.stapper at lijbrandt.nl> > Aan: Christian Grün <christian.gruen at 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 at 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
CG
Christian Grün20 May 2025 11:41 #
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/
Quoted text · Rob Stapper · 77 lines
On Tue, May 20, 2025 at 10:22 AM Rob Stapper via BaseX-Talk < basex-talk at 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 at lijbrandt.nl> > Aan: Christian Grün <christian.gruen at 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 at 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 > >
Written for BaseX 11.9. BaseX may have changed since: please check the current documentation.
⚡Generated with XQuery