Re: RFC 331 (v1) Consolidate the $1 and C<\1> notations

2000-09-29 Thread Piers Cawley
Jonathan Scott Duff <[EMAIL PROTECTED]> writes: > On Thu, Sep 28, 2000 at 08:57:39PM -, Perl6 RFC Librarian wrote: > > ${P1} means what $1 currently means (first match in last regex) > > I'm sorry that I don't have anything more constructive to say than > "ick", but ... Ick. I'm with the 'I

Re: RFC 332 (v1) Regex: Make /$/ equivalent to /\z/ under the '/s' modifier

2000-09-29 Thread Hugo
In <[EMAIL PROTECTED]>, Nathan Wiger writes: :> Is $$ the only alternative, or did I miss more? I don't think I've even :> seen this $$ mentioned before? : :$$ is not a suitable alternative. It already means the current process :ID. It really cannot be messed with. And ${$} is identical to $$ by :

Re: RFC 112 (v3) Asignment within a regex

2000-09-29 Thread Bart Lateur
On Fri, 29 Sep 2000 01:02:40 +0100, Hugo wrote: >It also isn't clear what parts of the expression are interpolated at >compile time; what should the following leave in %foo? > > %foo = (); > $bar = "one"; > "twothree" =~ / (?$bar=two) (?$foo{$bar}=three) /x; It's not just that. You act as if

Re: RFC 331 (v1) Consolidate the $1 and C<\1> notations

2000-09-29 Thread Hildo Biersma
> =head1 ABSTRACT > > Currently, C<\1> and $1 have only slightly different meanings within a > regex. Let's consolidate them together, eliminate the differences, and > settle on $1 as the standard. Sigh. That would remove functionality from the language. The reason why you need \1 in a regu

Re: RFC 112 (v3) Asignment within a regex

2000-09-29 Thread Richard Proctor
> On Fri, 29 Sep 2000 01:02:40 +0100, Hugo wrote: > > >It also isn't clear what parts of the expression are interpolated at > >compile time; what should the following leave in %foo? > > > > %foo = (); > > $bar = "one"; > > "twothree" =~ / (?$bar=two) (?$foo{$bar}=three) /x; > > It's not just

Re: RFC 316 (v1) Regex modifier for support of chunk processing and prefix matching

2000-09-29 Thread Bart Lateur
On Fri, 29 Sep 2000 00:29:31 +0100, Hugo wrote: >:I originally had thought of providing a separate, dedicated regex >:modifier, just for the match prefix, but I don't think too many people >:need this that desperately. You can easily build a working application >:with just the '/z' modifier. I

Re: RFC 316 (v1) Regex modifier for support of chunk processing and prefix matching

2000-09-29 Thread Hugo
In <[EMAIL PROTECTED]>, Bart Lateur writes: :On Fri, 29 Sep 2000 00:29:31 +0100, Hugo wrote: :>:I originally had thought of providing a separate, dedicated regex :>:modifier, just for the match prefix, but I don't think too many people :>:need this that desperately. You can easily build a workin

Re: RFC 112 (v3) Asignment within a regex

2000-09-29 Thread Hugo
In <[EMAIL PROTECTED]>, "Richard Proctor" writes: :In general all assignments should wait to the very end, and then assign :them all. [...] If the expression finally fails the localised values :would unroll. Ah, I hadn't anticipated that - I had assumed you would get whatever was the last value s

Re: RFC 316 (v1) Regex modifier for support of chunk processing and prefix matching

2000-09-29 Thread Bart Lateur
On Fri, 29 Sep 2000 13:19:47 +0100, Hugo wrote: >I think that involves >rewriting your /p example something like: > if (/^$pat$/z) { >print "found a complete match"; > } elsif (defined pos) { >print "found a prefix match"; > } else { >print "not a match"; > } Except that this isn

Re: RFC 331 (v1) Consolidate the $1 and C<\1> notations

2000-09-29 Thread Dave Storrs
On Thu, 28 Sep 2000, Hugo wrote: > :=item * > :/(foo)_C<\1>_bar/ > > Please don't do this: write C or /(foo)_\1_bar/, but > don't insert C<> in the middle: that makes it much more difficult to > read. Sorry; that was a global-replace error that I missed on proofreading. > :mean dif

Re: RFC 331 (v1) Consolidate the $1 and C<\1> notations

2000-09-29 Thread Dave Storrs
On Fri, 29 Sep 2000, Hildo Biersma wrote: > > Currently, C<\1> and $1 have only slightly different meanings within a > > regex. Let's consolidate them together, eliminate the differences, and > > settle on $1 as the standard. > > Sigh. That would remove functionality from the language. > >

Re: RFC 316 (v1) Regex modifier for support of chunk processing and prefix matching

2000-09-29 Thread Hugo
In <[EMAIL PROTECTED]>, Bart Lateur writes: :On Fri, 29 Sep 2000 13:19:47 +0100, Hugo wrote: : :>I think that involves :>rewriting your /p example something like: :> if (/^$pat$/z) { :>print "found a complete match"; :> } elsif (defined pos) { :>print "found a prefix match"; :> } else {

Re: RFC 348 (v1) Regex assertions in plain Perl code

2000-09-29 Thread Hugo
In <[EMAIL PROTECTED]>, Perl6 RFC Librarian writes: :=item assertion in Perl5 : : (?(?{not COND})(?!)) : (?(?{not do { COND }})(?!)) Or (?(?{COND})|(?!)). Migration could consider replacing detectable equivalents of such constructs with the favoured new construct. :"local" inside embedded code