On 29/11/12 23:13, Stephen Allen wrote:
Andy,
Thanks for the comments, very helpful. It is unfortunate that I
didn't look at this earlier in the year, but indeed my proposed change
would be relatively minor to the end user, and I've figured out a
solution staying within the current spec!
More comments inline:
On Thu, Nov 29, 2012 at 2:36 PM, Andy Seaborne <[email protected]> wrote:
Hi Stephen,
Adding requirements to the official SPARQL grammar by parsable in particular
ways is adding too much. The goal (SPARQL 1.0 and 1.1) is it''s LL(1) AKA
simple technically and that communicates. People can implement the language
in different ways and the grammar defines the language but it does not
prescribe the implementation.
In hindsight I would have argued that the optional terminating
semicolon should be eliminated to stay LL(1) without recursion.
It's there to make producing SPARQL Update syntax by (streaming!)
program easier - always put a SEMICOLON after an operation.
Actually, I didn't want a separator at all - it's not necessary. Oh well.
I had been trying that to no avail because of the unlimited amount of
lookahead required (which defeat the streaming effort). Syntactic
Lookahead to the rescue however, and I was able to write it as:
Prologue()
(
Update1()
(
// This syntactic lookahead is necessitated by the optional
trailing semicolon and prologue
LOOKAHEAD( <SEMICOLON> Prologue() ( <LOAD> | <CLEAR> | <DROP> | <ADD> |
<MOVE> | <COPY> | <CREATE> | <WITH> | <DELETE> | <INSERT> |
<USING> | <INSERT_DATA> | <DELETE_DATA> | <DELETE_WHERE> ) )
Does it have to be the tokens for the LOOKAHEAD?
?? refactor Update1 into the control part and the
( <LOAD> | ... | <DELETE_WHERE> ) list then share the list?
(My DRYistic tendencies!)
<SEMICOLON>
Prologue()
Update1()
)*
(
<SEMICOLON>
Prologue()
)?
)?
Andy
