-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
(Un)Checked Evaluation #709
Comments
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. |
No need for adding anything, as checked / unchecked are a good example of decorators. This comment contains details: #707 (comment) |
Feel free to finalize #106… |
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. |
As already stated in #707 (comment)
is equivalent to:
And a decorator can be applied to any function ( in this case equivalent to the expression)
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 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. |
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. |
I propose to close this one; I think it the vast majority would rarely use it in practice. |
The CG agreed to close this issue without action at meeting 066 |
Based on #707 (comment) and the comments following in that thread:
The text was updated successfully, but these errors were encountered: