>...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.
What you say has, I think, a great deal of sense. While Jon and
I--with Nathan, actually (see inside page credits)--were trying to
figure out how to go about presenting all this wacky stuff for the
final section of the new regex chapter in the Camel:
Fancy Patterns
Lookaround Assertions
Non-Backtracking Subpatterns
Programmatic Patterns
Generated patterns
Substitution evaluations
Match-time code evaluation
Match-time pattern interpolation
Conditional interpolation
Defining Your Own Assertions
We kept coming back to sentiments remarkably similar to those you
yourself have just expressed: although I think we managed to put a
decently positive shine on the matter for the print version, it
still really seems that that the inside-outness of this is very
hard on your brain, and of remarkably abstruse appeal to the
incredibly few. (Names of the usual suspects omitted to avoid using
four-letter words in public forums. :-)
I would welcome a less inside-out approach, as well as one that
were more procedural--or at least more symbolic and less punctuational.
--tom
