Re: XML/HTML-specific ?< and ?> operators? (was Re: RFC 145 (alternate approach))

----- Original Message -----
From: "Jonathan Scott Duff" <[email protected]>
Subject: Re: XML/HTML-specific ?< and ?> operators? (was Re: RFC 145
(alternate approach))


> On Wed, Sep 06, 2000 at 08:40:37AM -0700, Nathan Wiger wrote:
> > What if we added special XML/HTML-parsing ?< and ?> operators?
>
> What if we just provided deep enough hooks into the RE engine that
> specialized parsing constructs like these could easily be added by
> those who need them?
>
> -Scott

Ok, I've avoided this thread for a while, but I'll make my comment now.
I've played with several ideas of reg-ex extensions that would allow
arbitrary "parsing".  My first goal was to be able to parse perl-like text,
then later a simple nested parentheses, then later nested xml as with this
thread.

I have been able to solve these problems using perl5.6's recursive reg-ex's,
and inserted procedure code.  Unfortunately this isn't very safe, nor is it
'pretty' to figure out by a non-perl-guru.  What's more, what I'm attempting
to do with these nested parens and xml is to _parse_ the data.. Well, guess
what guys, we've had decades of research into the area of parsing, and we
came out with yacc and lex.  My point is that I think we're approaching this
the wrong way.  We're trying to apply more and more parser power into what
classically has been the lexer / tokenizer, namely our beloved
regular-expression engine.

A great deal of string processing is possible with perls enhanced NFA
engine, but at some point we're looking at perl code that is inside out: all
code embedded within a reg-ex.  That, boys and girls, is a parser, and I'm
not convinced it's the right approach for rapid design, and definately not
for large-scale robust design.

As for XML, we already have lovely c-modules that take of that.. You even
get your choice.  Call per tag, or generate a tree (where you can search for
sub-trees).  What else could you want?  (Ok, stupid question, but you could
still accomplish it via a customized parser).

My suggestion, therefore would be to discuss a method of encorportating more
powerful and convinient parsing within _perl_; not necessarily directly
within the reg-ex engine, and most likely not within a reg-ex statement.  I
know we have Yacc and Parser modules.  But try this out for size: Perl's
very name is about extraction and reporting.  Reg-ex's are fundamental to
this, but for complex jobs, so is parsing.  After I think about this some
more, I'm going to make an RFC for it.  If anyone has any hardened opinions
on the matter, I'd like to hear from you while my brain churns.

-Michael