ADQL-2.1 internal draft

[Ger van Diepen]

Operator precedence is not even clear to programmers, let alone to
users. Many people think that in C && and || have the same precedence
which is not true. Therefore compilers give a warning when using them
together without parentheses. 
Yet, I prefer operators to functions because they are less verbose and
more natural. I agree with Walter that parsing is quite straightforward
when using tools like bison/flex. I assume similar tools exist in the
Java world. 

I think the query must be written like 
     IN_UNIT(M, "solmass") < 10 
because the unit of M has to be converted to solmass (you know 10 is
specified as solmass). 

Some time ago I've had some discussion with Markus about units. Unlike
Markus I prefer to write the query like 
     M < 10 solmass 
Quotes are needed for composite units like 
     velocity < 3 'km/h'
In such grammar the unit specification is unambiguous and easy to parse
(I've done that in TaQL). I find it more natural and less confusing,
because that's the way we express it in normal language. I think it also
easier to write. 
I understood that ADQL is parsed and rewritten, so in principle such
syntax is possible. 

Cheers, 
Ger 

>>> Walter Landry <wlandry at caltech.edu> 6/10/2015 10:39 AM >>>
Markus Demleitner <msdemlei at ari.uni-heidelberg.de> wrote:
> Hi Walter,
>
> On Tue, Jun 09, 2015 at 04:53:26PM -0700, Walter Landry wrote:
>> 2) I do not understand the syntax for IN_UNIT().  Shouldn't there
be
>>    three arguments (value, units_from, units_to) and not two?
>
> No, the whole point is that query writers don't have to assume units
> in the query but let the database (or rather the translation layer)
> work it out for them.
>
> There are two reasons I've proposed this:
>
> (1) people get unit conversions wrong all the time, and the computer
> is much better reliably tracing units than humans are; also, it
helps
> writing a bit more generic queries
>
> (2) if people do manual unit conversions, there's no way a computer
> can reliably figure out the new unit, so your metadata is hosed.
>
> To satisfy both cases, it really needs to be a two-arg function.

Now I am really confused.  If I, as a query writer, want to find all
stars with mass M < 10*solMass, would I write

  M < IN_UNIT(10,"solMass")

or

  IN_UNIT(M,"solMass") < 10

>> 4) Can we put the math and trig functions into the optional
>>    components?  Most of them are not implemented in sqlite.
>
> ...but they're reasonably easy to retrofit, no?  In general, I'm
> against optional features, as they are a big liability on
> clients/users (that have to figure out where they are available).
> The code for adding trig to sqlite only needs to be written once, on
> the other hand (probably already has several times).

After a little wandering through the internet, I found

  http://sqlite.org/contrib/download/extension-functions.c?get=25

which implements most of these functions.  A little more work for me
(grumble, grumble), but not so bad.

>> 5) Why are we making new function names BIT_AND, BIT_OR, etc?  Why
not
>>    just use the operators?  It is what everyone but Oracle and
>>    Informix implement, and they use different names anyway.
>
> ...but operators are harder to parse (precedence!  Left-recursive
> rules!), and it's easier for a machine to go from prefix notation to
> infix than the other way round.  I'm all for functions.

We have to parse the operators anyway.  And it is really not
that hard.

Cheers,
Walter Landry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dal/attachments/20150610/47d100a7/attachment-0001.html>