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
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
:
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
> =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
> 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
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
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
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
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
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
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.
>
>
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 {
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
13 matches
Mail list logo