On Tue, 20 Nov 2001, Bill Kelly wrote:

> Checked out Rockit on Sourceforge, looks really nice!  From some of 
> the bullet points in your documentation it sounds like Rockit
> eliminates some of the aspects of lex+yacc that I've often thought
> seemed unfortunate or kinda messy (e.g. "No need to write a lexer/scanner;
> rockit gives you both a lexer and a parser from the same grammar." and, 
> "rockit-generated parsers builds the AST; NO need to write ``action code''
> in the grammar. ``Action code'' separated from grammar.")
> 
Well thanks. Speed is currently the problem though, but I haven't worked
on that yet. Want to get the semantics right first...

> By the way, out of curiosity is the "rockit-grammar.grammar" file
> actually used somehow, or is it just an example of what the grammar
> _would_ be...?  You haven't found some way to pull it up by its own
> bootstraps have you!??  ;-)
> 
It bootstraps itself each time someone installs it. Its not really
difficult; you simply give a crude way to write grammars directly in Ruby
and then you write a parser for rockit grammars within it. Then use that
parser to parse the Rockit grammar files grammar and output a parser and
you're all set. Good thing is that its a fairly extensive test that things
are working.

> > Ps. If you're not familiar with regular vs. non-regular grammars then the
> > canoncial example of what the former cannot do is balanced/nested
> > parentheses. You can't do it with one regexp (although people have shown
> > how to do it with one (two?) regexps and supporting code). In a
> > "formalism" supporting non-regular grammars it's no problem.
> 
> Yes, in fact it was this that got me started.  The Perl (??{ })
> extension provides at least a way to specify such a construct
> in a regexp.  From the perlre doc: (slightly rubified)
> 
Ok, interesting. Will you be writing this in Ruby or C?

>  (??{ code })
> 
>    This is a ``postponed'' regular subexpression.  The code is evaluated
>    at run time, at the moment this subexpression may match.  The result
>    of evaluation is considered as a regular expression and matched as
>    if it were inserted instead of this construct.
> 
>    re = %r{
>              \(
>              (?:
>                 (?> [^()]+ )    # Non-parens without backtracking
>               |
>                 (??{ re })      # (Sub-)group with matching parens
>              )*
>              \)
>           }x
> 
> 
> (I'm also considering having (??) be shorthand for 'this-regex', which 
> would look like...
> 
>    re = %r{
>              \(
>              (?:
>                 (?> [^()]+ )    # Non-parens without backtracking
>               |
>                 (??)            # (Sub-)group with matching parens
>              )*
>              \)
>           }x
> 
> ...and which also wouldn't require interaction with the Ruby parser.
> But I'm hoping to be able to do the more general (??{ code }) version
> too.)
> 
Ok, then your stuff will be very much like Rockit's new framework. We
should probably keep contact as things develop.

The above "regexp" can for example be written 

  non_paren = plus( any_but( "(", ")" ) ) 
  re = seq("(", (non_paren || recurse), ")")

in the Rockit parser combinators but I'm not sure of a good syntax to
write the recursion. Unfortunately :?? doesn't work or we could use the
same "symbol"...

Regards,

Robert