ADQL: Bitwise operators

[Markus Demleitner]

Hi Ger,

On Thu, Feb 15, 2018 at 08:08:55AM +0100, Ger van Diepen wrote:
> I do not understand why it should be so much work to change the
> precedence of operators in existing code. If a tool such as
> flex/bison is used, it is really trivial. I assume similar tools
> exist for Java.

Trivial certainly is too strong -- from my experience, grammar
changes are never trivial, in particular if you're changing the root
of the most common expression (and I'd count the fact that the PR
grammar is, at the very least, problematic for <bitwise_expression>
as evidence).  I count more than 30 occurrences of it in the ADQL 2.0
BNF, and blindly searching and replacing them with
<bitwise_expression> sounds like a bad plan to me.

And as I said, it's not just the grammar, it's the annotation and
morphing code, too, that needs to be changed.

Doable, sure, but is it worth it for just a bit of syntax for
something that quite clearly isn't used all that often.

Well, let's see if people have put in the effort in ADQL
implementations.

> Also note the precedence of OR and AND. I don???t know how it is
> defined in ADQL, but normally AND has a higher precedence than OR
> which many people do not realise. Therefore many compilers give a

Same thing in ADQL: NOT is a boolean_factor, AND is a boolean_term,
and, and OR is directly in search condition.  So, indeed, NOT binds
more strongly and AND, and AND more strongly than OR.

> I???ve never understood why function names (in SQL and ADQL) have
> to be reserved words; in principle it makes it impossible (in a
> backward compatible way) to add new functions because somewhere
> columns with such names could exist. Every parser (with 1
> look-ahead) should be able to distinguish between a column name and
> a function name using the subsequent opening parenthesis.

Well, actually ADQL *has* non-reserved function names, those of
user-defined functions. Also, most actual SQL engines have functions
with non-reserved names.

So, there's no technical reason I can see (except that it's
marginally easier to produce useful error messages with reserved
words), and your objection that adding reserved words can in
princible break existing queries is both valid and profound.  Still,
reserving function names is SQL style, and at least for the BITWISE_X
thing, I'd say pragmatically there's no need to deviate from it.

On the other hand, I'd not object to add a symbol
<unreserved_function_call> that would probably sit next to
<user_defined_function> if people preferred that.

        -- Markus