>>> > * 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
> "NT" == Nathan Torkington <[EMAIL PROTECTED]> writes:
>> > * Using an array of "words" as an alternate list as part of a regex
>> /match any of (${\join'|',@list}) here/
NT> $" = "|"; /@list/ # snicker
Is $" one of the specials scheduled for the axe?
--
Chaim Frenkel
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://neti
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?
Well, that all depends what the meaning of the word work
On Fri, Aug 18, 2000 at 03:15:54PM -0700, Steve Fink wrote:
> There would still be a use of a /f like flag, though -- treat all (...)
> like (?:...). That would make the regex more likely to be DFA-able, and
> is often what I want but I don't want to clutter up my regex with those
> nasty ?:'s eve
On Fri 18 Aug, Damian Conway wrote:
>> All of these can be done today but are not necessarily "easy".
>>
>
> /\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,
> > /\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?
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 woul
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
> 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 not
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?
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 aca
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 (${\
> 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 no
14 matches
Mail list logo
