Re: comment on A.7 "Grammar"

Fred Zemke wrote:
> 
> A.7 Grammar
> There are no commas in the SELECT list.  This looks like a poor
> design because it will be an obstacle to allowing arbitrary
> expressions in the SELECT list in a future version.  I asked for
> arbitrary expressions in a previous round of comments, and was told
> that this was being deferred to the future.  That is fine, but I want
> to insure that the ground is ready for that extension. 

I'd like to ensure we leave space for expressions in the SELECT clause.  There 
are various ways it could be done even within the current syntax.  When the WG 
was designing the syntax, there was a feeling at the time (not a formal 
decision) that if there weren't comma in triples patterns (an old syntax idea 
was () round triple patterns as in RDQL) then, for uniformity, no commas 
anywhere.  That principle as a long time ago and hasn't been revisited and 
theer wasn't ORDER BY at the time.

The current syntax uses variables, functions and built-ins, together with 
bracketed expressions.  It doesn't have unbracketed expressions appearing at 
the top level place where expressions occur.

So in keeping with that, expressions could be added to SELECT as (spur of the 
moment designs):

SELECT (?y := ?a + ?b)      # An assignment operator
SELECT (?a + ?b) AS ?y      # expression + name
SELECT ?y:-(?a + ?b)        # N3-like naming operator.

These may not be the best design but I've just checked those forms by 
extending the current grammar and it is still LL(1) with a fixed token set.

(The XML Results format requires names for each binding.)

> Strictly speaking, commas may be unnecessary since SELECT ?a ?b + ?c
> can be parsed.

Unbracketed expressions would need commas to know when they end and a new one 
start.  Given we are in CR, mandatory commas would be a significant change.

>  The issue is that this is not very friendly to the
> user because having commas to separate expressions is an opportunity
> for the parser to catch typos.  I note that our syntax for
> function calls requires commas between successive expressions, even
> though there too they are not strictly necessary.
> 
> ORDER BY also lacks commas, so if we add them to SELECT we
> should probably add them to ORDER BY.

Agreed - they should be the same.

> 
> Fred
> 

I hope I've shown that expressions in SELECT are possible.

	Andy

Received on Saturday, 10 June 2006 19:35:48 UTC