- From: Dan Connolly <connolly@w3.org>
- Date: Wed, 17 Aug 2005 17:55:56 -0500
- To: Richard Newman <r.newman@reading.ac.uk>
- Cc: public-rdf-dawg-comments@w3.org, Yosi Scharf <syosi@MIT.EDU>
Richard Newman wrote: > > Hello all, > As SPARQL is in last call, I've been asked to provide some feedback > based on my experiences of implementing twinql[1]. > [1] <http://www.holygoat.co.uk/projects/twinql/> > [2] <http://wilbur-rdf.sourceforge.net/> > [3] <http://www.holygoat.co.uk/blog/entry/2005-07-12-3> Thanks.... I'm noting a few specific points... > The parser was a little less exciting to develop. I used CL-YACC, a > yacc-like parser generator for Common Lisp. This required: > > • Translating the EBNF grammar into s-expression BNF productions > • Writing a lexer > • Wiring actions into the productions to output the s-expressions. > > Translating the grammar was no fun at all. Firstly, the EBNF had to > be manually translated into BNF, requiring the creation of a number > of intermediate productions. Secondly, the grammar is beyond the > reach of a simple parser generator, requiring lookahead -- not a > difficulty for the Java compiler tool being used, but too much for CL- > YACC. Thus, implementing the parser needed continual switching back > to the lexer, shifting the complicated "smarts" into the generation > of tokens. The lexer is therefore quite complex, applying various > regular expressions, producing symbols, resolving URIs, and building > literals. One unavoidable issue was the optional dot after the last > query element in each graph pattern. This made the grammar ambiguous, > so twinql currently makes them compulsory. I'm looking for a better > solution. I've heard grumbles about that from other places too. Yosi, is this the same part of the grammar you were working on? [...] -- Dan, not using his usual email client
Received on Wednesday, 17 August 2005 22:56:00 UTC