On 08.05.2010 22:48, Rony G. Flatscher wrote: >>> One caveat though: regular expressions are very powerful, but (since a >>> lot of Perlish style (PCRE) in the form of cryptic letters at certain >>> positions meaning something specific, shines through) hard to learn and >>> hard to keep the acquired knowledge, if one does not use them for a >>> longer time. Being confronted with people who are beginners in learning >>> a programming language, regular "regular expressions" are something >>> almost unbearable for them. So one idea would be to try to come up with >>> some "Rexxish" notation for the regex in addition to the "pure" one, >>> which will be a boon for the regex-experts. E.g. coming up with an >>> encoding for the regex patterns that make it instantenous clear that a >>> pattern is greedy, lazy/reluctant or possessive, or all the >>> non-capturing lookaround "(?" patterns and the like. The Rexxish >>> version should be as self-describable as possible (such that one does >>> not need to look-up the regex documentation to learn what the meaning of >>> an expression would be in effect). >>> >>> The goal would be that Rexx programmers who have never dealt with regex >>> the power of your implementation may become easily tangible. And of >>> course, all ideas would be helpful that would allow to define a Rexxish >>> interface to this powerful regex package. >>> >>> >> The package was designed with this possibility in mind. Unlike the >> Java versions, I've maintained a clean separation between the Pattern >> class and the .RegexCompiler class. Any number of compilers can be >> written to provide integration, and even the Pattern engine can be >> extended by writing addtional MatchNode subclasses. All it takes is >> for somebody to define such an expression language and write a >> compiler for that. I'm not prepared to do such a think. When I first >> came up with the idea of doing this, I challenged Chip to come up with >> a language, but I've seen no action on that front. One problem with >> trying to do something like that is the language tends to become very >> "wordy". For example, that URL example above in a less terse syntax >> would be several times the size. On the other hand, with reusable >> pieces, that example becomes easier to understand because you pattern >> starts to read more like a BNF description. Indeed, you could >> probably write a compiler that could build pattern matches from a BNF >> grammer description. >> Indeed, some variant of BNF may be a more Rexxish approach.
Just looked up a possible (rather complex) BNF definition of url at <http://www.w3.org/Addressing/URL/5_BNF.html>, which also shows the complexity of an url production. ---rony ------------------------------------------------------------------------------ _______________________________________________ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
