Eric Mahurin wrote: >> compare: >> space = Grammar::Element[Set[?\ ,?\t].duck!(:==,:include?)].discard > So, doing 1..3, in the released grammar v0.5, you'd have this instead: > space = (E[?\s] | E[?\t]).discard Definitely an improvement! >> Nathan's concept is that "grammar" should become a Ruby keyword, > I don't think ruby needs any new keywords. It already has more than it > needs in my opinion. There is enough power with just classes, methods, > blocks, and operator overloading. Part of the point of using a packrat-style parser is that there are no true keywords, meaning words that must only be used in their KW places. Many of Ruby's words are like that, of course. But my point was that once you say "grammar", you're now talking a different language, which can use as much and *only* as much of the Ruby grammar as it needs. And when inside a rule you say {, you're back in Ruby grammar... etc. The normal lexer/parser split makes that fairly hard to do, as the lexer needs to know whether to return the KW meaning or a general identifier. >> Ruby DSL is far too awkward to express CQL - which is my primary >> project at present. > Don't know anything about CQL to answer. I would like to make what I have > general enough. Take a look at the ORM diagrams under the images directory, and then at the CQL version of the same models, under <http://activefacts.rubyforge.org/svn/examples/>. You'll see a lot of what looks like unparsable plain English... but it's not. In fact, the language is much harder to parse than any of those examples, I don't have any published examples of queries (these are just declarations). The CQL parser is in <http://activefacts.rubyforge.org/svn/lib/activefacts/cql/> - you might be able to see where it's hard. You can be many tokens into recognising a fact_clause before realising you're looking at a "condition". It's possible that with your lookahead it would be possible though. >> to see how to do it, whereas it won't ever happen with yours AFAICS. > It definitely could happen with mine. I do ruby code generation now, but > could have another Grammar-like class Cool! I didn't realize you were generating code from this. > But, if you use the #lookahead method on any > grammar, it will give a new grammar that handles the case when the grammar > fails in the middle (backtracks to the position where the grammar started). You mean it backtracks to the start of the file? Or to where you called lookahead? Clifford Heath.