> "Jarkko" == Jarkko Hietaniemi <[EMAIL PROTECTED]> writes:
>> "You want Icon, you know where to find it..." :)
Jarkko> Hey, it's one of the few languages we haven't yet stolen a
Jarkko> neat feature or few from... (I don't really count the few
Jarkko> regex thingies as full-fledged stealin
On Wed, Sep 06, 2000 at 03:47:57PM -0700, Randal L. Schwartz wrote:
> > "Mark-Jason" == Mark-Jason Dominus <[EMAIL PROTECTED]> writes:
>
> Mark-Jason> I have some ideas about how to do this, and I will try to
> Mark-Jason> write up an RFC this week.
>
> "You want Icon, you know where to find
> > "Mark-Jason" == Mark-Jason Dominus <[EMAIL PROTECTED]> writes:
>
> Mark-Jason> I have some ideas about how to do this, and I will try to
> Mark-Jason> write up an RFC this week.
>
> "You want Icon, you know where to find it..." :)
That's exactly my motivation. It seems to me that tryi
> "Mark-Jason" == Mark-Jason Dominus <[EMAIL PROTECTED]> writes:
Mark-Jason> I have some ideas about how to do this, and I will try to
Mark-Jason> write up an RFC this week.
"You want Icon, you know where to find it..." :)
But yes, a way that allows programmatic backtracking sort of "inside
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Boolean Regexes
=head1 VERSION
Maintainer: Richard Proctor <[EMAIL PROTECTED]>
Date: 6 Sep 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Number: 198
Status
I've been tossing an idea around in my head, and I've not yet decided if
this is the most brilliant idea I've ever come up with:), or perhaps the
lamest. I'm sure it would be cool, but that doesn't mean it should be
pursued. I'm going to throw this one out in the open, and if it's not
shot full
> >...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.
I've been thinking the same thing. It seems to me that the attempts
Jonathan Scott Duff wrote:
>
> 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
- Original Message -
From: "Richard Proctor" <[EMAIL PROTECTED]>
Sent: Tuesday, September 05, 2000 1:49 PM
Subject: Re: RFC 145 (alternate approach)
> On Tue 05 Sep, David Corbin wrote:
> > Nathan Wiger wrote:
> > > But, how about a new ?m operator?
> > >/(?m<<|[).*?(?M>>|])/;
> The
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Numberic Value Ranges In Regular Expressions
=head1 VERSION
Maintainer: David Nicol <[EMAIL PROTECTED]>
Date: 5 september 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Number: 197
Status: Deve
>I am working on an RFC
>to allow boolean logic ( && and || and !) to apply a number of patterns to
>the same substring to allow easier mining of information out of such
>constructs.
What, you don't like: :-)
$pattern = $conjunction eq "AND"
? join('' => map { "(?=.*$_)" }
On Wed 06 Sep, David Corbin wrote:
> Nathan Wiger wrote:
> >
> > > It would be useful (and increasingly more common) to be able to match
> > > qr|<\s*(\w+)([^>]*)>| to qr|<\s*/\1\s*>|, and handle the case where
> > > those can nest as well. Something like
> > >
> > > match this with
> > >
>...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
>engin
David Corbin wrote:
>
> m:(?['' => '').*(?]):
>
> or more generically
>
> m:(?['<\w+>' => '').*(?]):
I think these are good; but I do also like the idea of "automatic
reversing" by default, since that's a common operation.
Let's combine the ideas, as Richard suggests. How about:
1. When a
- 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 ?> operato
On Tue 05 Sep, Nathan Wiger wrote:
>"normal" "reversed"
>-- ---
>103301
>99aa99
>(( ))
><+ +>
>{{[!<_ _>!]}}
>{__A1( )A1__}
>
> That is, when a bracket is encountered, the
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
--
Jon
Nathan Wiger wrote:
>
> > It would be useful (and increasingly more common) to be able to match
> > qr|<\s*(\w+)([^>]*)>| to qr|<\s*/\1\s*>|, and handle the case where those
> > can nest as well. Something like
> >
> > match this with
> >
> > not this but
> >this.
>
> I suspec
> It would be useful (and increasingly more common) to be able to match
> qr|<\s*(\w+)([^>]*)>| to qr|<\s*/\1\s*>|, and handle the case where those
> can nest as well. Something like
>
> match this with
>
> not this but
>this.
I suspect this is going to need a ?[ and ?] of its
At 09:05 AM 9/6/00 -0400, David Corbin wrote:
>I'd suggest also, that (?[) (with no specified brackets) have the
>default meaning
>of the "four standard brackets" :
>
>(?['('=>')','{'=>'}','['=>']','<'=>'>')
>
>Note also the subtle syntax change. We are either dealing with strings
>or with patter
I'd suggest also, that (?[) (with no specified brackets) have the
default meaning
of the "four standard brackets" :
(?['('=>')','{'=>'}','['=>']','<'=>'>')
Note also the subtle syntax change. We are either dealing with strings
or with patterns. The consensus seems to be against patterns (I can
21 matches
Mail list logo
