(Un)Checked Evaluation

[ChristianGruen]

Based on #707 (comment) and the comments following in that thread:

I've been thinking recently about adding checked{} and unchecked{} modes. For example

<xsl:apply-templates select="checked{.//item}"/>

would throw an error if there are no items. The mode of execution would propagate downwards, so checked{a/b/c/d} would be able to tell you that a b was found, but it had no c children.

checked{item[22]} would have the effect of making sequences behave more like arrays, with bound checking; conversely unchecked{item?22} would return an empty sequence instead of throwing an error.

[ChristianGruen]

From the XQuery point of view, I think it’s better to avoid introducing new expression for evaluation directives. A workable solution for us was to rely on existing language features (although the syntax could be a bit more compact).

The following example shows how function inlining can be disabled on three levels:

(: 1. globally, applies to the complete module :)
declare option db:inlinelimit '0';

(: 2. function level: apply to the function body :)
declare %db:inlinelimit(0) function local:function() { }

(: 3. locally: apply to the enclosed expression :)
(# db:inlinelimit 0 #) {
  local:function()
}

We could do the same for disabling/enabling checked evaluation in expressions …but I asuume that annotations and/or pragmas would first need to be added to XPath.

[dnovatchev]

We could do the same for disabling/enabling checked evaluation in expressions …but I asuume that annotations and/or pragmas would first need to be added to XPath.

No need for adding anything, as checked / unchecked are a good example of decorators.

This comment contains details: #707 (comment)

[ChristianGruen]

No need for adding anything, as checked / unchecked are a good example of decorators.

Feel free to finalize #106…

[michaelhkay]

No need for adding anything, as checked / unchecked are a good example of decorators.

I don't think so. Firstly, they apply to expressions rather than functions. Secondly, they have nested scope (could be static or dynamic, but I prefer static) - they apply not only to the immediate expression, but to all subexpressions.

Of course, it would need some experiments to see if this actually works (in the sense of making debugging easier). It's possible that there are too many expressions that deliberately return an empty sequence to make the idea feasible.

[dnovatchev]

No need for adding anything, as checked / unchecked are a good example of decorators.

I don't think so. Firstly, they apply to expressions rather than functions.

As already stated in #707 (comment)

SomeExpr($arg1, $arg2, ..., $argN)

is equivalent to:

fn($arg1, $arg2, ..., $argN) {SomeExpr($arg1, $arg2, ..., $argN)}

And a decorator can be applied to any function ( in this case equivalent to the expression)

Secondly, they have nested scope (could be static or dynamic, but I prefer static) - they apply not only to the immediate expression, but to all subexpressions.

Of course, it would need some experiments to see if this actually works (in the sense of making debugging easier). It's possible that there are too many expressions that deliberately return an empty sequence to make the idea feasible.

As already pointed out in #707 , relying on the empty sequence in general to denote some special/error value is wrong, because the empty sequence is a legitimate value returned by a map or array lookup.

So much for "they apply to all subexpressions".

Excluding from "all subexpressions" all subexpressions that don't contain any array or map lookup, may seem useful, but to me needing such a "feature" clearly shows that something is wrong with the language itself.

As this issue was originally raised for maps, the most natural and elegant solution I am aware of is setting the value of the default-key of the map (#105) to whatever best would represent "empty" (or "no result"), for example:

let $price-for-night := map {
1 : 100,
2 : 90,
3 : 80
'\' : ()
}
  return
    $price-for-night(10)

for hotel nightly prices, where people are allowed to stay at the hotel for no more than 3 nights.

Even in this particular example, a better value for the \ key would best be: xs:double("INF")

And an expression may contain lookups on different maps for which we may want to have different default values returned.

Thus, again the "one size fits all" approach is not applicable in this general case.

[dnovatchev]

As for applying a decorator to "an expression and all its subexpression", this can be done by decorating the expression-evaluator itself, and returning a new expression evaluator function that instead of raising an error in particular situations, returns a "special value" instead.

Even if we do not introduce Decorators in the language, the fact remains that the proposed (Un)Checked Evaluation is equivalent to such decorator.

[ChristianGruen]

I propose to close this one; I think it the vast majority would rarely use it in practice.

[ndw]

The CG agreed to close this issue without action at meeting 066