Re: fn:stack-trace

I wonder how Java and other languages handle this? Does the fact that the program can call for a stack-trace inhibit any optimizations like tail-call optimization or function inlining? My assumption was that stack-trace() would just do the best it could to present any information that's available at run-time and hasn't been optimized away (and it might give you more information if optimizations have been disabled).

Michael Kay
Saxonica

> On 2 Dec 2020, at 10:53, Christian Grün <cg@basex.org> wrote:
> 
> The description for fn:stack-trace is fairly general and vague [1]. I
> think that’s just fine, as the specs do not prescribe how to implement
> function invocations.
> 
> “Stack trace” implies to me that the function will return the call
> stack (i.e., the stack of invoked functions). As this may only be
> fully possible if functions are not inlined at compile time, code
> might need to be compiled differently whenever a stack trace request
> is found… and so forth. The name also implies to me that the function
> should return nothing else. However, it could be helpful to get a list
> of bound variables with their values at runtime.
> 
> Maybe we can find a more general name, such as fn:debug or fn:runtime-trace?
> 
> Cheers,
> Christian
> 
> [1] Returns implementation-dependent information about the current
> state of execution.
>