Re: Possibility of lazy evaluation of static parameters / variables / use-when / shadow attributes

We've got a strong statement in 2.13

<quote>
Errors classified in this specification as static errors must be signaled by all implementations: that is, the processor must indicate that the error is present. A static error must be signaled even if it occurs in a part of the stylesheet that is never evaluated.
</quote>

and my previous attempts to relax that have not found favour with the WG. But there's always scope for a product to provide configuration options that say "I know it's not conformant but do it anyway".

The XPath spec is even stricter. It imposes a temporal requirement: the dynamic evaluation phase is not allowed to start until the static analysis phase is finished. I regard that as a completely inexcusable requirement, and not enforceable because it is not testable. I've made yet another attempt to get rid of it in my review of the XPath spec.

Michael Kay
Saxonica


> On 7 Oct 2016, at 16:15, Abel Braaksma <abel.braaksma@xs4all.nl> wrote:
> 
> It is interesting that you mention that (the deferred JIT compilation). We are currently failing some tests because we don't raise a static error, simply because a construct is never used and for most constructs (notably declarations), we defer compilation until it is needed. For instance, if a static variable is never used, and it uses itself a variable that is not declared, it may never raise an error (conversely, we *do* raise XPath syntax errors).
> 
> Considering that you are on the same path, we may think of something spec-wise? I have not been able to find where we say that static expressions *must* raise an error in the static phase, but it may be inferred from the fact that static errors themselves *must* be raised.
> 
> While in my original mail I expressed my preference for requiring such errors to be raised, I think there's something to be said for lazy compilation. XPath (and by extension, XSLT) has a class of errors that are considered static, but these aren't necessarily syntax errors (i.e., a function name that is not found is not a syntax error, but still raises a static error).
> 
> The example with an unknown function is interesting: a function may be available from a separate library. Both Java and .NET, iirc, JIT-compile a library on first use. It can be beneficial for performance if a named function call only requires resolution on moment of its use (if never used, the containing library is never called, and is never JITted).
> 
> Cheers,
> Abel
> 
>> -----Original Message-----
>> From: Michael Kay [mailto:mike@saxonica.com]
>> Sent: Friday, October 07, 2016 9:34 AM
>> To: Abel Braaksma
>> Cc: Public XSLWG
>> Subject: Re: Possibility of lazy evaluation of static parameters / variables /
>> use-when / shadow attributes
>> 
>> The status quo in the spec is that you're not allowed to do any dynamic
>> evaluation if the stylesheet contains any static errors, and that would include
>> (I think) a dynamic error in the evaluation of a static expression.
>> 
>> Having said that, we're probably going to start introducing user-selectable JIT
>> compilation options that might defer static analysis of some constructs until
>> they are first used, whether the spec allows it or not. We're spending too
>> much time repeatedly compiling DocBook stylesheets that contain 500
>> template rules designed to process elements that don't actually appear in
>> your source document.
>> 
>> Michael Kay
>> Saxonica
>> 
>> 
>>> On 7 Oct 2016, at 00:04, Abel Braaksma <abel.braaksma@xs4all.nl> wrote:
>>> 
>>> In many places in the spec we mention or hint that a processor is not
>> required to evaluate an unused variable. How does this work for static
>> parameters and variables? Do we require them to be processed? I browsed
>> through the use-when and shadow attribute sections but couldn't readily
>> find this.
>>> 
>>> This may be important, for instance to detect static errors resulting from
>> the dynamic evaluation of static expressions.
>>> 
>>> Example:
>>> 
>>> <xsl:variable name="x" use-when="1 div 0 eq 0" />
>>> 
>>> A processor may statically know that this variable is never used. Is it
>> allowed to forego the error and process the stylesheet regardless? I'm
>> inclined to say no, and that static expressions (use-when, static
>> variables/parameters, shadow attributes) must *always* be evaluated. This
>> follows from the notion of compile-time errors in other languages, of which
>> static expressions are an extension.
>>> 
>>> Other example:
>>> 
>>> <xsl:mode name="m" _streamable="doc('settings.xml')/*/@streamable"
>> />
>>> 
>>> It is possible that the document settings.xml contains an invalid setting for
>> the streamable attribute. However, if a processor can statically infer that
>> mode "m" is never used (it should be able to do so), then does it have to load
>> settings.xml and process it?
>>> 
>>> Again, I'm inclined to say yes: static errors must always be reported.
>>> 
>>> It gets fuzzier with static variables/parameters, since we already say about
>> variables that they only need to be evaluated when they are actually used:
>>> 
>>> <xsl:variable name="foo" static="yes" select="xs:error('oh oh')"/>
>>> 
>>> If no other static, or dynamic expression uses $foo, can it be ignored? Even
>> here, I'd say: no, static expressions can never be ignored and should
>> therefore be crafted more carefully than dynamic expressions.
>>> 
>>> Note: no bug raised, I am not sure there's something wrong here.
>>> 
>>> Cheers,
>>> Abel
>>> 
>>> 
>> 
> 
> 
>

Received on Friday, 7 October 2016 17:01:05 UTC