On 11/28/05, Nikolai Weibull
<mailing-lists.ruby-talk / rawuncut.elitemail.org> wrote:
> > > So you think /(?:abc)/ is easier to read than /[abc]/?  How about
> > > /\w+\s*=\s*\w+/ versus /<word> = <word>/w (or
> > > /<word><ws>=<ws><word>/ without 'w' modifier and assuming word =
> > > /\w+/)?
>
> > No, but I don't think that they're regular expressions at that point.
>
> No, but what we call regular expressions aren't in any way regular
> either.  Actually, it depends on how this is actually done.  In Perl 6,
> <word> will call the regex in the current grammar called 'word', so
> that's certainly not regular.  If <word> is simply substituted by
> whatever 'word' is defined to in the current grammar, then that doesn't
> change anything.

I don't think trying to push full parser capabilities into regex's is
the right way to go.  Instead, I think we should have a standard OO
mechanism in ruby to build grammars - and easily put actions in.  So,
in your example above, I think we should be able to do something like
this:

# we previously defined word, ws, and equal
assign = word + ws + equal + ws + word

This is exactly how my grammar package works.  It is LL, but this same
way of defining grammars could be used LR/LALR parsing or
DFA/NFA/backtracking of regular expressions.  Instead of specifing
your entire parser in a very complex string (the regular expression),
you simply create and combine grammars using methods to make your
parser (the most basic methods would be for creating an element,
sequencing (+), alternation (|), and recursion).  You could easily
associate actions (i.e. ruby blocks) with certain elements with what
you are trying to parse.  And since this is OO (and duck-typed), we
wouldn't be limited to just parsing characters like regex's - we could
parse tokens or whatever.