Why does XQuery treat the following expressions differently?
() = 2 returns false (general Comparison)
() eq 2 returns an empty sequence (value Comparison)
This effect is explained in the XQuery specifications. For XQuery 3, it is in chapter 3.7.1, Value Comparisons (highlighting added by me):
Atomization is applied to the operand. The result of this operation is called the atomized operand.
If the atomized operand is an empty sequence, the result of the value comparison is an empty sequence, and the implementation need not evaluate the other operand or apply the operator. However, an implementation may choose to evaluate the other operand in order to determine whether it raises an error.
Thus, if you're comparing two single element sequences (or scalar values, which are equal to those), you will as expected receive a true/false value:
1 eq 2 is false
2 eq 2 is true
(1) eq 2 is false
(2) eq 2 is true
(2) eq (2) is true
and so on
But, if one or both of the operands is the empty list, you will receive the empty list instead:
() eq 2 is ()
2 eq () is ()
() eq () is ()
This behavior allows you to pass-through empty sequences, which could be used as a kind of null value here. As #adamretter added in the comments, the empty sequence () has the effective boolean value of false, so even if you run something like if ( () eq 2) ..., you won't observe anything surprising.
If any of the operands contains a list of more than one element, it is a type error.
General comparison, $sequence1 = $sequence2 tests if any element in $sequence1 has an equal element in $sequence2. As this semantically already supports sequences of arbitrary length, no atomization must be applied.
Why?
The difference comes from the requirements imposed by the operators' signatures. If you compare sequences of arbitrary length in a set-based manner, there is no reason to include any special cases for empty sequences -- if an empty sequence is included, the comparison is automatically false by definition.
For the operators comparing single values, one has to consider the case where an empty sequence is passed; the decision was to not raise an error, but also return a value equal to false: the empty sequence. This allows to use the empty sequence as a kind of null value, when the value is unknown; anything compared to an unknown value can never be true, but must not (necessarily) be false. If you need to, you could check for an empty(...) result, if so, one of the values to be compared was unknown; otherwise they're simply different. In Java and other languages, a null value would have been used to achieve similar results, in Haskell there's the Data.Maybe.
Related
In the tryapl.org Primer when you select the Del glyph (∇) it shows an example of a Double-Del (∇∇) where a dop (as I understand it, a user defined operator) can reference itself in a recursive fashion:
Double-Del Syntax: dop self-reference
pow←{ ⍝ power operator: apply ⍵⍵ times
⍵⍵=0:⍵ ⍝ ⍵⍵ is 0: finished
⍺⍺ ∇∇(⍵⍵-1)⍺⍺ ⍵ ⍝ otherwise: recurse
}
Can someone provide me with some examples of this particular dop in use so I can see how to utilize it? I see that a single ⍺ is not used in the body of this dop, only ⍺⍺; does that make this a monadic dop?
I have tried a number of different ways to use this operator in an expression after it's defined and can't seem to get anything but errors or instances where it appears the body/text of the dop is in an array as text, alongside what I was trying to pass to it.
Example usage
incr←{1+⍵} ⍝ define an increment function
(incr pow 3) 5 ⍝ apply it 3 times to 5
8
Lack of single ⍺
The operator has ⍵⍵ which alone makes it a dyadic operator. The lack of a single ⍺ means that, when given the two required operands, it derives a monadic function.
Troubleshooting
When an operator takes an array (as opposed to a function) operand adjacent to an argument, it is crucial to separate the operand from the argument. This can be done in any of three ways:
Name the derived function and then apply it:add3←incr pow 3
add3 5
Parenthesise the derived function:(incr pow 3) 5
Separate the operand from the argument using a function (often, the identity function ⊢ is used): incr pow 3 ⊢ 5
Failing this, the intended operand and argument will strand to a single array, which then becomes the operand, leaving the derived function with no argument that it can apply to:
incr pow (3 5)
The result is therefore the derived function; the text source you see reported.
In Practical Common Lisp, Peter Seibel write:
The mechanism by which multiple values are returned is implementation dependent just like the mechanism for passing arguments into functions is. Almost all language constructs that return the value of some subform will "pass through" multiple values, returning all the values returned by the subform. Thus, a function that returns the result of calling VALUES or VALUES-LIST will itself return multiple values--and so will another function whose result comes from calling the first function. And so on.
The implementation dependent does worry me.
My understanding is that the following code might just return primary value:
> (defun f ()
(values 'a 'b))
> (defun g ()
(f))
> (g) ; ==> a ? or a b ?
If so, does it mean that I should use this feature sparingly?
Any help is appreciated.
It's implementation-dependent in the sense that how multiple values are returned at the CPU level may vary from implementation to implementation. However, the semantics are well-specified at the language level and you generally do not need to be concerned about the low-level implementation.
See section 2.5, "Function result protocol", of The Movitz development platform for an example of how one implementation handles multiple return values:
The CPU’s carry flag (i.e. the CF bit in the eflags register) is used to signal whether anything other than precisely one value is being returned. Whenever CF is set, ecx holds the number of values returned. When CF is cleared, a single value in eax is implied. A function’s primary value is always returned in eax. That is, even when zero values are returned, eax is loaded with nil.
It's this kind of low-level detail that may vary from implementation to implementation.
One thing to be aware: there is a limit for the number of values which can be returned on a specific Common Lisp implementation.
The variable MULTIPLE-VALUES-LIMIT has the implementation/machine specific value of the maximum numbers of values which can be returned. The standard says that it should not be smaller than 20. SBCL has a very large number on my computer, while LispWorks has only 51, ECL has 64 and CLISP has 128.
But I can't remember seeing Lisp code which wants to return more than 5 values.
I'm confused with the below query, I expect the result should be 5 but it returns an empty sequence.
let $num := 5
let $num1 := ()
let $add := $num + $num1
return $add
I don't know how close Marklogic XQuery is to the W3C XQuery standard but in that standard the rules for arithmetic expressions https://www.w3.org/TR/2010/REC-xquery-20101214/#id-arithmetic clearly say
The first step in evaluating an arithmetic expression is to evaluate
its operands. The order in which the operands are evaluated is
implementation-dependent.
Each operand is evaluated by applying the following steps, in order:
Atomization is applied to the operand. The result of this operation is
called the atomized operand.
If the atomized operand is an empty sequence, the result of the
arithmetic expression is an empty sequence
So the empty sequence is the defined result as one operand is the empty sequence.
Perhaps the sum() function, let $add := sum(($num, $num1)), is more what you are looking for.
Trying to create my first Coq definitions after doing many tutorials. Wondering how to define something simple like an alphabet, if the definition is:
Σ is an alphabet iff it's a finite nonempty set of symbols.
Got this much:
Require Import Coq.Lists.ListSet.
Definition alphabet := set.
But how do you specify the "must be a finite, non-empty set" part?
Since you choose your alphabet to be set, it is by definition finite, since set is defined as an instance of list, and inductive types are always finite.
The ListSet library you are using defines emptyset so your first option would be to state that
Definition not_empty (a: alphabet) : Prop := a <> empty_set.
Or you could rely on the fact that your set is list and pattern match on the expression:
Definition not_empty (a: alphabet) : bool := match a with
| nil => false
| _ => true
end.
(You can also define the latter in Prop instead of bool by using False and True.)
EDIT: Some clarification asked by Arthur (Simplification here, grab a real text-book about inductive types if you want a more precise explanation):
An inductive type can be inhabited by:
a finite number of elements (for example, bool),
an infinite number of elements (for example, nat)
no element at all (for example False).
However, any element of an inductive type is by construction finite. For example you can write any natural number by composing a finite number of time the constructor S but you have to use O at some point and ''stop'' the construction of your term. Same goes for lists: you can build an arbitrary long list, but its length will always be finite.
I was reading some PL/SQL documentation, and I am seeing that NULL in PL/SQL is indeterminate.
In other words:
x := 5;
y := NULL;
...
IF x != y THEN -- yields NULL, not TRUE
sequence_of_statements; -- not executed
END IF;
The statement would not evaluate to true, because the value of y is unknown and therefore it is unknown if x != y.
I am not finding much info other than the facts stated above, and how to deal with this in PL/SQL. What I would like to know is, when would something like this be useful?
This is three valued logic, see http://en.wikipedia.org/wiki/Three-valued_logic, and - specific for SQL - in http://en.wikipedia.org/wiki/Null_(SQL).
It follows the concept that a NULL value means: this value is currently unknown, and might be filled with something real in future. Hence, the behavior is defined in a way that would be correct in all cases of future non-null values. E. g. true or unknown is true, as - no matter if the unknown (which is the truth value of NULL) will later be replaced by something that is true or something that is false, the outcome will be true. However, true and unknown is unknown, as the result will be true if the unknown will later be replaced by a true value, while it will be false, if theunknown` will later be replaced by something being false.
And finally, this behavior is not "non determinictic", as the result is well defined, and you get the same result on each execution - which is by definition deterministic. It is just defined in a way that is a bit more complex than the standard Boolean two-valued logic used in most other programming languages. A non-deterministic function would be dbms_random.random, as it returns a dfferent value each time it is called, or even SYSTIMESTAMP, which also returns different values if called several times.
You can find good explanation why NULL was introduced and more in Wikipedia.
In PL/SQL you deal with NULL by
using IS (NOT) NULL as a comparision, when you would like to test against NULL
using COALESCE and NVL functions, when you want to substitute NULL with something else, like here IF NVL(SALARY, 0) = 0