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 patterns. The consensus seems to be against patterns (I can
>understand that). Given that, we need to quote the right hand side of
>the => operator I think. The quotes on the left side would be optional,
>I think.
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
<list> match this with
<list>
</list> not this but
</list> this.
>Richard Proctor wrote:
> >
> > On Tue 05 Sep, Nathan Wiger wrote:
> > > Eric Roode wrote:
> > > Now *that* sounds cool, I like it!
> > >
> > > What if the RFC only suggested the addition of two new constructs, (?[)
> > > and (?]), which did nested matches. The rest would be bound by standard
> > > regex constructs and your imagination!
> > >
> > > That is, the ?] simply takes whatever the closest ?[ matched and
> > > reverses it, verbatim, including ordering, case, and number of
> > > characters. The only trick would be a way to get what "reverses it"
> > > means correct.
> > >
> >
> > No ?] should match the closest ?[ it should nest the ?[s bound by any
> > brackets in the regex and act accordingly.
> >
> > Also this does not work as a definition of simple bracket matching as you
> > need ( to match ) not ( to match (. A ?[ list should specify for each
> > element what the matching element is perhaps
> >
> > (?[( => ),{ => }, 01 => 10)
> >
> > sort of hashish in style.
> >
> > Perhaps the brackets could be defined as a hash allowing (?[%Hash)
> >
> > Richard
> >
> > --
> >
> > [EMAIL PROTECTED]
>
>--
>David Corbin
>Mach Turtle Technologies, Inc.
>http://www.machturtle.com
>[EMAIL PROTECTED]
