Inconsistent lazy evaluation between debug and non-debug

[bwrrp]

Consider the following test case:

let $fn := function($trigger as xs:boolean, $arg as array(*)) { if ($trigger) then ($arg[1]) else () } return $fn(true(), ())

This should (and does) throw an error XPTY0004 as the $arg argument is the empty sequence, not an array. However, now consider what happens if we set $trigger to false():

let $fn := function($trigger as xs:boolean, $arg as array(*)) { if ($trigger) then ($arg[1]) else () } return $fn(false(), ())

This technically does not use the $arg argument, so I'm not sure if it's required to throw here? Unfortunately though, the behavior is different depending on the value of the debug option. Worse, it throws only if debug is off, leading to errors that typically only occur in production setups.

With debug: true: returns "" (assuming evaluation to STRING)

With debug: false: throws Uncaught Error: XPTY0004: Multiplicity of function argument of type array(*) for dynamic-function is incorrect. Expected exactly one

[DrRataplan]

The stack frame things might not propagate their expected return type in the static phase. Odd.

…

On Thu, 26 Jun 2025, 11:49 Stef Busking, ***@***.***> wrote: *bwrrp* created an issue (FontoXML/fontoxpath#676) <#676> Consider the following test case: let $fn := function($trigger as xs:boolean, $arg as array(*)) { if ($trigger) then ($arg[1]) else () } return $fn(true(), ()) This should (and does) throw an error XPTY0004 as the $arg argument is the empty sequence, not an array. However, now consider what happens if we set $trigger to false(): let $fn := function($trigger as xs:boolean, $arg as array(*)) { if ($trigger) then ($arg[1]) else () } return $fn(false(), ()) This technically does not use the $arg argument, so I'm not sure if it's required to throw here? Unfortunately though, the behavior is different depending on the value of the debug option. Worse, it throws only if debug is off, leading to errors that typically only occur in production setups. With debug: true: returns "" (assuming evaluation to STRING) With debug: false: throws Uncaught Error: XPTY0004: Multiplicity of function argument of type array(*) for dynamic-function is incorrect. Expected exactly one — Reply to this email directly, view it on GitHub <#676>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABGKEJEZTHE3GCVQIOYVRID3FO62RAVCNFSM6AAAAACAFWH2U2VHI2DSMVQWIX3LMV43ASLTON2WKOZTGE3TQNJSHEZTONQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[bwrrp]

Digging into this a bit with the debugger, the difference seems to indeed be the result of the wrapping StackTraceGenerator expressions, but perhaps not in the way you'd expect.

The function call logic uses ISequence.switchCases to apply the type multiplicity check. In case the argument is a known-length sequence type such as EmptySequence in the example, that is implemented in a way that performs the check immediately. However, if it is an IteratorBackedSequence, its implementation of switchCases merely bakes the check into the resulting iterator, to be performed lazily when it is iterated over (which never happens).

I'm not entirely sure what the best approach would be here. I think there is something to be said for having function calls always perform the type check on all arguments at the point where the call happens. That would probably require forcing some iteration (at least two values to confirm matching multiplicity) of the transformedArgument in transformArgumentList to ensure the check actually happens there? Or is there some other way we can achieve this?

Alternatively we could achieve consistency by forcing this check to always happen lazily, e.g., by always wrapping function call arguments in an iterator-based sequence. That might of course make it harder to discover actual bugs...

[DrRataplan]

I think we could also add some logic in the stacktrace generator that can see if a sequence is of a known length, it returns a sequence of a known length again. I'm even up for a instance of check there. Or even better, use the sequence.getLength(true) to pass the onlyIfCheap argument, and passing that to sequenceFactory when we wrap the sequence in the stack frame generator.. That can then in the switchCases be picked up to hit the correct case right away. Making the error hit immediately in all cases!