Re: twinql Retrospective (optional dot grammar woes)

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