Re: Extended Regexs
* Using an array of "words" as an alternate list as part of a regex
/match any of (${\join'|',@list}) here/
NT $" = "|"; /@list/ # snicker
Certainly I've written
if (do { local $" = "|"; $var =~ /@any/}) { blah() }
before.
--tom
Re: Extended Regexs
On Fri, Aug 18, 2000 at 08:46:17PM +0100, Richard Proctor wrote: There is one significant area of perl that has very little attention here (other than one of my RFCs) that is regexs. Are you volunteering to chair a sublist? *grin* K. -- Kirrily Robert -- [EMAIL PROTECTED] -- http://netizen.com.au/ Open Source development, consulting and solutions Level 10, 500 Collins St, Melbourne VIC 3000 Phone: +61 3 9614 0949 Fax: +61 3 9614 0948 Mobile: +61 410 664 994
Re: Extended Regexs
/\A(?s:(?!and).)*\Z/
/pattern returned from ${\some_function} as part of a regex/
/match any of (${\join'|',@list}) here/
I am not saying these things can't be done, in fact I was saying they can
but was rather asking what should be made easier?
Perhaps I was suggesting: "none of the above".
:-)
Damian
Extended Regexs
Hi, There is one significant area of perl that has very little attention here (other than one of my RFCs) that is regexs. Perl has very powerfull regexs - but what other features might be desirable? I had one long term good idea on assignment and submitted that, but there may be other things people have thought - wouldn't it be nice if, - I wish XXX was easiler? Here is a few throw away thoughts - they don't constitute RFC material yet, I am not sure if they would be that useful and have not yet thought of any syntax, but any others? All of these can be done today but are not necessarily "easy". * Embeded patterns that do not match a pattern - you can do [^a]* for a string that does not have an a, but can you match a string that does not contain "and". * Repeated sub patterns - qr allows you to compile a pattern, but if you want to use a same sub pattern as part of many regexs this is not easy. (The keyword there is PART). * Using the pattern returned from some function as part of a regex * Using an array of "words" as an alternate list as part of a regex * Fill your idea in here [ ] Richard Proctor [ Years ago I did a significant pattern matching package (for another computer language), and know quite a lot about the theories so I am not exactly a novice] [[ Enough free time between now and Sunday Lunchtime [1] to be on list for once ]] [1] And the start of the next business trip... -- [EMAIL PROTECTED]
Re: Extended Regexs
Here is a few throw away thoughts - they don't constitute RFC
material yet, I am not sure if they would be that useful and have
not yet thought of any syntax, but any others? All of these can be
done today but are not necessarily "easy".
* Embeded patterns that do not match a pattern - you can do [^a]*
for a string that does not have an a, but can you match a string
that does not contain "and".
/\A(?s:(?!and).)*\Z/
* Using the pattern returned from some function as part of a regex
/pattern returned from ${\some_function} as part of a regex/
* Using an array of "words" as an alternate list as part of a regex
/match any of (${\join'|',@list}) here/
Damian
Re: Extended Regexs
Damian Conway writes:
* Using the pattern returned from some function as part of a regex
/pattern returned from ${\some_function} as part of a regex/
(??{ some_function() }) more generally
* Using an array of "words" as an alternate list as part of a regex
/match any of (${\join'|',@list}) here/
$" = "|"; /@list/ # snicker
Nat
Re: Extended Regexs
On Fri, Aug 18, 2000 at 08:46:17PM +0100, Richard Proctor wrote: There is one significant area of perl that has very little attention here (other than one of my RFCs) that is regexs. Perl has very powerfull regexs - but what other features might be desirable? Well, one thing that has acatualy come up (on -language-io, BCCed) is less powerful regexes. Specificly, making an additional /f modifer that told the compiler to use a faster DFA matcher instead of the default super-powerful, but slow one. (/d for DFA has been proposed, but I rather like f for Finite and Fast.) The DFA engine's language would be a proper subset of the full regex engine's, and at least version 8 regular expressions: character classes, alternitivies, grouping parens (not certian about capturing parens, def no backreferencing). The idea is that putting a /f on should (almost) always increase speed, but won't allow as much expressiveness. -=- James Mastros -- -BEGIN GEEK CODE BLOCK- Version: 3.1 GUCS d--- s-:- a20 C++ UL+++@ P L++@ E-() N o? K? w@ M-- !V PS++ PE Y+ PGP(-) t++@ 5+ X+++ R+ tv+ b+++ DI+ D+ G e++ h! r- y? --END GEEK CODE BLOCK--
Re: Extended Regexs
James Mastros wrote: On Fri, Aug 18, 2000 at 08:46:17PM +0100, Richard Proctor wrote: There is one significant area of perl that has very little attention here (other than one of my RFCs) that is regexs. Perl has very powerfull regexs - but what other features might be desirable? Well, one thing that has acatualy come up (on -language-io, BCCed) is less powerful regexes. Specificly, making an additional /f modifer that told the compiler to use a faster DFA matcher instead of the default super-powerful, but slow one. (/d for DFA has been proposed, but I rather like f for Finite and Fast.) The choice of algorithms is a great idea, but why do we need a modifier? Isn't it a pretty straightforward set of rules that allow us to decide if a DFA matcher will work? It would be a lot nicer if Perl could just notice that the regex could be handled by its DFA matcher, all by itself.
Re: Extended Regexs
James Mastros wrote: [/f for fast DFA regexen] Jeremy Howard wrote: The choice of algorithms is a great idea, but why do we need a modifier? Isn't it a pretty straightforward set of rules that allow us to decide if a DFA matcher will work? It would be a lot nicer if Perl could just notice that the regex could be handled by its DFA matcher, all by itself. That would be nice, too, but a modifier would let you ensure that the DFA matcher was being used. You wouldn't have to guess whether a particular construct was DFA-able or not. -- Robert Mathews Software Engineer Excite@Home
Re: Extended Regexs
Robert Mathews wrote: James Mastros wrote: [/f for fast DFA regexen] Jeremy Howard wrote: The choice of algorithms is a great idea, but why do we need a modifier? Isn't it a pretty straightforward set of rules that allow us to decide if a DFA matcher will work? It would be a lot nicer if Perl could just notice that the regex could be handled by its DFA matcher, all by itself. That would be nice, too, but a modifier would let you ensure that the DFA matcher was being used. You wouldn't have to guess whether a particular construct was DFA-able or not. A modifier to ensure that the DFA was not used would be nice too. -- Mathieu Arnold
Re: Extended Regexs
On Sat, Aug 19, 2000 at 07:57:34AM +1000, Jeremy Howard wrote: The choice of algorithms is a great idea, but why do we need a modifier? Isn't it a pretty straightforward set of rules that allow us to decide if a DFA matcher will work? clintonWell, that all depends what the meaning of the word work is./clinton Specificly, there may be cases where the normal matcher will return different results then the DFA matcher, but we wanted the DFA one anyway. Also, using the /f modifier promisses things about interpolated scalars, which can't be determinied by the compiler. -- -BEGIN GEEK CODE BLOCK- Version: 3.1 GUCS d--- s-:- a20 C++ UL+++@ P L++@ E-() N o? K? w@ M-- !V PS++ PE Y+ PGP(-) t++@ 5+ X+++ R+ tv+ b+++ DI+ D+ G e++ h! r- y? --END GEEK CODE BLOCK--
