On Fri, Nov 30, 2012 at 6:43 AM, Andy Seaborne <[email protected]> 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 <[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!) >
I agree about DRY, but in this case I believe it is unavoidable. 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
