[xquery-talk] What do people do about warnings?

James A. Robinson jim.robinson at stanford.edu
Fri Jan 12 03:32:04 PST 2007


> Any other way to do this would involve using implementation specific 
> constructs.
> 
> I'm surprised that you find it necessary to try to fool the query 
> optimiser into not getting rid of your trace() function call. I would 
> consider it a bug if it was optimised out of your query - certainly the 
> XQuery implementations I work on would not do that.

I seem to recall reading that this very topic was a point of worry for
some in that some implementations, those in a language with access to a
compiler with an aggressive optimizer, had some worries about the profile
of a function whose response was unused in the execution of a program.

If I recall correctly, the worry was that the lower level optimizations,
those in a JIT for example, or even at the hardware level, might optimize
such a call away.

That looks to me like what is going on here. When I had

  let $w := (trace($node, $message))
  return ()

I could turn on tracing and see that this was being called, but nothing
gets emitted to STDERR (per this engines handling of fn:trace).  When
I changed it to

  let $w := (trace($node, $message))
  return if (exists($w)) then () else ()

the STDERR messages showed up.  The really odd thing was that

  let $w := (trace($node, $message))
  return if ($w) then () else ()

Causes a fatal error when $node is a sequence of items (in this
case a pair of URIs as in ($uri1, $uri2) in which both were of
type xs:anyURI.  I'm still trying to figure this last thing out,
it feels like a bug to me but I'm not sure yet.

Jim

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
James A. Robinson                       jim.robinson at stanford.edu
Stanford University HighWire Press      http://highwire.stanford.edu/
+1 650 7237294 (Work)                   +1 650 7259335 (Fax)


More information about the talk mailing list