On 01/12/12 07:39, Stephen Allen wrote:
On Fri, Nov 30, 2012 at 6:43 AM, Andy Seaborne <a...@apache.org> wrote:
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 <a...@apache.org> 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!)
I agree about DRY, but in this case I believe it is unavoidable.
Doh! yes, you're right - it is. Via Update1 each token is tied to the
action for the token which is side-effecting. Lookahead will get weird.
Andy
The
paths are kind of separate. If the grammar were written with:
LOOKAHEAD( <SEMICOLON> Prologue() Update1() )
It would probably work, but it would require evaluating Update1()
completely before making a decision at the choice point. Since
Update1() could possibly contain a very long INSERT_DATA or
DELETE_DATA, that would defeat the streaming. Instead, since we just
list the options for the first token that could possibly appear in the
Update1, then we can stop the lookahead there without evaluating the
contents of the update operation.
See the "SYNTACTIC LOOKAHEAD" section of the JavaCC mini-tutorial [1]
if you're interested in a better explanation than I can give.
-Stephen
[1] http://javacc.java.net/doc/lookahead.html
