Operators

[Roland Bouman]

Hi!

it seems to me the expression syntax was designed to look like
javascript. If that is the case, then I'm wondering about the list of
operators:
In the syntax notes I see these operators:

Comparison Operators: == < <= > >= != <>
Bitwise Operators: & | ~ << >>

I'm wondering why the strict comparison operators === and !== and the
bitwise XOR (^) and zero-filled right-shift (>>>) weren't included.
Is this an omission, or is this intentional?

(I realize the ++, -- are also missing but I am assuming that is
intentional to keep the expression syntax free from side effects. Is
that assumption correct?)

[p...@pi.net]

My mental model for UnQL is that as each document is accessed, it is
converted by JSON.parse into a javascript value, the arithmetic is
performed and the resulting value is converted back to a string by
JSON.stringify. This string is then stored or returned.

I'm not saying that this is how an actual implementation should work,
it is just a way of expressing the semantics of the UnQL language.
Note that the current spec and the current sample code on http://unql.sqlite.org
has somewhat different semantics, and I guess we can debate what the
semantics should be.

In the above mental model, all of ===, !==, ==, !=, ^, ++ and -- have
well specified meanings and could simply be added. However, whether
the javascript semantics for comparison are usable in a database
context is up for debate, with eg. both 2<{} and 2>={} returning false
in javascript.

[Roland Bouman]

Hi! thanks for the reply :-)

On Aug 12, 1:12 pm, "p...@pi.net" <p...@pi.net> wrote:
> My mental model for UnQL is that as each document is accessed, it is
> converted by JSON.parse into a javascript value, the arithmetic is
> performed and the resulting value is converted back to a string by
> JSON.stringify. This string is then stored or returned.

This is exactly what I assumed too :)

> In the above mental model, all of ===, !==, ==, !=, ^, ++ and -- have
> well specified meanings and could simply be added. However, whether
> the javascript semantics for comparison are usable in a database
> context is up for debate, with eg. both 2<{} and 2>={} returning false
> in javascript.

Funny, I see no problem with regard to comparison operators, where I
do see a problem with ++ and --.
I mean, sure, the examples you mention here look counterintuitive, but
it's well defined in any context.
++, -- have the effect of changing the value of their operand.
That means that order of evaluation suddenly starts to matters. sad :(

[p...@pi.net]

(i) The issue with the comparison operators is when used to define
sorting (ORDER BY, indexes). Would 2 sort before or after {} if both
2<{} and 2>={} return false? Or should the order be left undefined?
The JS built-in function Array.sort sidesteps this issue by converting
values to strings before doing (string) comparison in its default
comparison function. Is that what UnQL should do?

(ii) Sure, order of evaluation would have impact, but not more so then
on the value of 'b' in:
var a = 3;
var b = a++ + a++ * 2;
As it happens, both v8 and jscript 5 set b to 11, which is perhaps not
what you would expect.
Hence I see no problem with -- and ++ being UnQL operators, although I
do not see an obvious use case either.

Paul

[Roland Bouman]

The main problem I see with ++ and -- is that they suggest the
document should be changed persistently.

Anyway, the topic of my post was about a set of operators which I
believe do not have side-effects in normal javascript.
If the language authors can shed their light on why they omitted ++
and --, then that would be great too of course.