Re: $/ not always set after a regex match?

[Vadim Belman]

There are little known operators `andthen`, `orelse`, `notandthen` (I always 
forget about the latter one too). What you are looking for would be:

given $s { m/ $=\w+ / andthen ..say }

Or, if you want a named variable:

given ("aaa") { (my $m = m/$=\w+/) andthen $m..say }

Best regards,
Vadim Belman

> On Jan 2, 2023, at 5:07 PM, yary  wrote:
> 
> I like statement modifiers, though not so much using side-effect variables 
> set by a postfix modifier, I'd like to see the side effect before seeing the 
> variable it sets. Something like
> 
> / .+  / && put "The root of $_ is $/.";
> 
> though the discussion is about not setting $/ in the caller's context and I'm 
> not sure how to rewrite it with the matching operation first and passing the 
> match result to a named variable and also skipping if no match, all in a 
> single statement.
> 
> -y
> 
> 
> On Sat, Dec 31, 2022 at 8:10 PM William Michels via perl6-users 
> mailto:perl6-users@perl.org>> wrote:
>> RESENDING: The code examples below should read `` in all cases, 
>> not ``, although either works (erroneously?).
>> 
>> ---
>> 
>> Interested in answering the question:
>> 
>> WHICH CODE EXAMPLE IS THE PRETTIEST?
>> 
>> Vote for your favorite (or post your own):
>> 
>> [#] > #REPL (line numbers altered to differentiate)
>> Nil
>> [0] > $_ = 'gracefully'
>> gracefully
>> [1a] > put "The root of $_ is $/." if / .+  /;
>> The root of gracefully is graceful.
>> [1b] > put "The root of $_ is $<>." if / .+  /;
>> The root of gracefully is graceful.
>> [1c] > print "The root of $_ is " andthen put $/ ~ '.' if / .+  
>> /;
>> The root of gracefully is graceful.
>> [1d] > print "The root of $_ is " andthen put $<> ~ '.' if / .+  
>> /;
>> The root of gracefully is graceful.
>> [1] >
>> [2a] > put "Or is the root of $_ $/?" if / .+  /;
>> Or is the root of gracefully grace?
>> [2b] > put "Or is the root of $_ $<>?" if / .+  /;
>> Or is the root of gracefully grace?
>> [2c] > print "Or is the root of $_ " andthen put $/ ~ '?' if / .+ > full> /;
>> Or is the root of gracefully grace?
>> [2d] > print "Or is the root of $_ " andthen put $<> ~ '?' if / .+ > full> /;
>> Or is the root of gracefully grace?
>> [#] >
>> 

Re: $/ not always set after a regex match?

[yary]

I like statement modifiers, though not so much using side-effect variables
set by a postfix modifier, I'd like to see the side effect before seeing
the variable it sets. Something like

/ .+  / && put "The root of $_ is $/.";

though the discussion is about not setting $/ in the caller's context and
I'm not sure how to rewrite it with the matching operation first and
passing the match result to a named variable and also skipping if no match,
all in a single statement.

-y


On Sat, Dec 31, 2022 at 8:10 PM William Michels via perl6-users <
perl6-users@perl.org> wrote:

> RESENDING: The code examples below should read `` in all
> cases, not ``, although either works (erroneously?).
>
> ---
>
> Interested in answering the question:
>
> WHICH CODE EXAMPLE IS THE PRETTIEST?
>
> Vote for your favorite (or post your own):
>
> [#] > #REPL (line numbers altered to differentiate)
> Nil
> [0] > $_ = 'gracefully'
> gracefully
> [1a] > put "The root of $_ is $/." if / .+  /;
> The root of gracefully is graceful.
> [1b] > put "The root of $_ is $<>." if / .+  /;
> The root of gracefully is graceful.
> [1c] > print "The root of $_ is " andthen put $/ ~ '.' if / .+  ly> /;
> The root of gracefully is graceful.
> [1d] > print "The root of $_ is " andthen put $<> ~ '.' if / .+  ly> /;
> The root of gracefully is graceful.
> [1] >
> [2a] > put "Or is the root of $_ $/?" if / .+  /;
> Or is the root of gracefully grace?
> [2b] > put "Or is the root of $_ $<>?" if / .+  /;
> Or is the root of gracefully grace?
> [2c] > print "Or is the root of $_ " andthen put $/ ~ '?' if / .+  full> /;
> Or is the root of gracefully grace?
> [2d] > print "Or is the root of $_ " andthen put $<> ~ '?' if / .+
>  /;
> Or is the root of gracefully grace?
> [#] >
>
>

Re: $/ not always set after a regex match?

[Vadim Belman]

A side effect is a side effect, it's something we cannot generally predict and 
must not rely upon. Besides, that effect is caused by a regex which is a 
separate entity on its own.

The primary point is that your sequence objects gets `.sink` method invoked on 
it because the object itself is, roughly saying, unused.

Best regards,
Vadim Belman

> On Dec 30, 2022, at 4:44 PM, Sean McAfee  wrote:
> 
> On Fri, Dec 30, 2022 at 4:12 PM The Sidhekin  > wrote:
>> On Fri, Dec 30, 2022 at 8:51 PM Vadim Belman > > wrote:
>>> It is not "untrue". The sequence you produced goes nowhere. Thus the sink 
>>> context.
>> 
>>   "Sink context" is true.
>> 
>>   "Useless use" is debatable, at least.
> 
>  It's not useless because there's a side effect: setting $/.
> 

Fwd: $/ not always set after a regex match?

[William Michels via perl6-users]

RESENDING: The code examples below should read `` in all
cases, not ``, although either works (erroneously?).

---

Interested in answering the question:

WHICH CODE EXAMPLE IS THE PRETTIEST?

Vote for your favorite (or post your own):

[#] > #REPL (line numbers altered to differentiate)
Nil
[0] > $_ = 'gracefully'
gracefully
[1a] > put "The root of $_ is $/." if / .+  /;
The root of gracefully is graceful.
[1b] > put "The root of $_ is $<>." if / .+  /;
The root of gracefully is graceful.
[1c] > print "The root of $_ is " andthen put $/ ~ '.' if / .+ 
/;
The root of gracefully is graceful.
[1d] > print "The root of $_ is " andthen put $<> ~ '.' if / .+  /;
The root of gracefully is graceful.
[1] >
[2a] > put "Or is the root of $_ $/?" if / .+  /;
Or is the root of gracefully grace?
[2b] > put "Or is the root of $_ $<>?" if / .+  /;
Or is the root of gracefully grace?
[2c] > print "Or is the root of $_ " andthen put $/ ~ '?' if / .+  /;
Or is the root of gracefully grace?
[2d] > print "Or is the root of $_ " andthen put $<> ~ '?' if / .+  /;
Or is the root of gracefully grace?
[#] >

Re: $/ not always set after a regex match?

[William Michels via perl6-users]

Interested in answering the question:

WHICH CODE EXAMPLE IS THE PRETTIEST?

Vote for your favorite (or post your own):

[#] > #REPL (line numbers altered to differentiate)
Nil
[0] > $_ = 'gracefully'
gracefully
[1a] > put "The root of $_ is $/." if / .+  /;
The root of gracefully is graceful.
[1b] > put "The root of $_ is $<>." if / .+  /;
The root of gracefully is graceful.
[1c] > print "The root of $_ is " andthen put $/ ~ '.' if / .+ 
/;
The root of gracefully is graceful.
[1d] > print "The root of $_ is " andthen put $<> ~ '.' if / .+  /;
The root of gracefully is graceful.
[1] >
[2a] > put "Or is the root of $_ $/?" if / .+  /;
Or is the root of gracefully grace?
[2b] > put "Or is the root of $_ $<>?" if / .+  /;
Or is the root of gracefully grace?
[2c] > print "Or is the root of $_ " andthen put $/ ~ '?' if / .+  /;
Or is the root of gracefully grace?
[2d] > print "Or is the root of $_ " andthen put $<> ~ '?' if / .+  /;
Or is the root of gracefully grace?
[#] >


On Fri, Dec 30, 2022 at 1:44 PM Sean McAfee  wrote:

> On Fri, Dec 30, 2022 at 4:12 PM The Sidhekin  wrote:
>
>> On Fri, Dec 30, 2022 at 8:51 PM Vadim Belman  wrote:
>>
>>> It is not "untrue". The sequence you produced goes nowhere. Thus the
>>> sink context.
>>>
>>
>>   "Sink context" is true.
>>
>>   "Useless use" is debatable, at least.
>>
>
>  It's not useless because there's a side effect: setting $/.
>
>

Re: $/ not always set after a regex match?

[Sean McAfee]

On Fri, Dec 30, 2022 at 4:12 PM The Sidhekin  wrote:

> On Fri, Dec 30, 2022 at 8:51 PM Vadim Belman  wrote:
>
>> It is not "untrue". The sequence you produced goes nowhere. Thus the sink
>> context.
>>
>
>   "Sink context" is true.
>
>   "Useless use" is debatable, at least.
>

 It's not useless because there's a side effect: setting $/.

Re: $/ not always set after a regex match?

[The Sidhekin]

On Fri, Dec 30, 2022 at 8:51 PM Vadim Belman  wrote:

> It is not "untrue". The sequence you produced goes nowhere. Thus the sink
> context.
>

  "Sink context" is true.

  "Useless use" is debatable, at least.


Eirik

Re: $/ not always set after a regex match?

[Vadim Belman]

It is not "untrue". The sequence you produced goes nowhere. Thus the sink 
context.

Best regards,
Vadim Belman

> On Dec 30, 2022, at 11:08 AM, Sean McAfee  wrote:
> 
> Ah, got it, thanks.
> 
> It's mildly vexing, but the kind of side-effecty coding I described isn't a 
> great idea in general.  I only stumbled across the phenomenon while code 
> golfing.
> 
> As a side note, code like this:
> 
> sub f { 1 ... * ~~ /9/; $/ }
> 
> ...produces an untrue warning "Useless use of ... in sink context".  Not sure 
> if it's worth filing a bug report...
> 
> On Wed, Dec 28, 2022 at 12:49 PM Elizabeth Mattijsen  > wrote:
>> That's because it at one time was decided that smart-match would set $/ in 
>> the caller's scope.  Which is a pain for implementation and optimizations.  
>> I would be very much in favour of getting rid of that "feature", fwiw.
>> 
>> > On 28 Dec 2022, at 18:45, Sean McAfee > > > wrote:
>> > 
>> > But if a sequence has its own $/, why does * ~~ /9/ set $/?
>> > 
>> > Actually it's not just sequences, as a little more experimentation showed:
>> > 
>> > [0] > first /9/, ^Inf
>> > 9
>> > [1] > $/
>> > Nil
>> > [2] > grep /9/, ^10
>> > (9)
>> > [3] > $/
>> > Nil
>> > 
>> > The * ~~ "trick" sets $/ in these cases too.
>> > 
>> > 
>> > On Wed, Dec 28, 2022 at 12:01 PM Elizabeth Mattijsen > > > wrote:
>> > This isn't specific to the REPL:
>> > 
>> > $ raku -e 'say 1 ... /9/; say $/'
>> > (1 2 3 4 5 6 7 8 9)
>> > Nil
>> > 
>> > I can only assume that the sequence has its own scope for $/, and thus 
>> > isn't visible outside of it.
>> > 
>> > 
>> > Liz
>> > 
>> > > On 28 Dec 2022, at 16:47, Sean McAfee > > > > wrote:
>> > > 
>> > > In a fresh 2022.12 Raku REPL, when the endpoint of a sequence is a 
>> > > Regex, the $/ variable seems not to be set:
>> > > 
>> > > [0] > 1 ... /9/
>> > > (1 2 3 4 5 6 7 8 9)
>> > > [1] > $/
>> > > Nil
>> > > 
>> > > If I match more explicitly using a WhateverCode, it works:
>> > > 
>> > > [2] > 1 ... * ~~ /9/
>> > > (1 2 3 4 5 6 7 8 9)
>> > > [3] > $/
>> > > ｢9｣
>> > > 
>> > > Is this the intended behavior, or a bug?
>> > > 
>> > 
>> 

Re: $/ not always set after a regex match?

[Sean McAfee]

Ah, got it, thanks.

It's mildly vexing, but the kind of side-effecty coding I described isn't a
great idea in general.  I only stumbled across the phenomenon while code
golfing.

As a side note, code like this:

sub f { 1 ... * ~~ /9/; $/ }

...produces an untrue warning "Useless use of ... in sink context".  Not
sure if it's worth filing a bug report...

On Wed, Dec 28, 2022 at 12:49 PM Elizabeth Mattijsen  wrote:

> That's because it at one time was decided that smart-match would set $/ in
> the caller's scope.  Which is a pain for implementation and optimizations.
> I would be very much in favour of getting rid of that "feature", fwiw.
>
> > On 28 Dec 2022, at 18:45, Sean McAfee  wrote:
> >
> > But if a sequence has its own $/, why does * ~~ /9/ set $/?
> >
> > Actually it's not just sequences, as a little more experimentation
> showed:
> >
> > [0] > first /9/, ^Inf
> > 9
> > [1] > $/
> > Nil
> > [2] > grep /9/, ^10
> > (9)
> > [3] > $/
> > Nil
> >
> > The * ~~ "trick" sets $/ in these cases too.
> >
> >
> > On Wed, Dec 28, 2022 at 12:01 PM Elizabeth Mattijsen 
> wrote:
> > This isn't specific to the REPL:
> >
> > $ raku -e 'say 1 ... /9/; say $/'
> > (1 2 3 4 5 6 7 8 9)
> > Nil
> >
> > I can only assume that the sequence has its own scope for $/, and thus
> isn't visible outside of it.
> >
> >
> > Liz
> >
> > > On 28 Dec 2022, at 16:47, Sean McAfee  wrote:
> > >
> > > In a fresh 2022.12 Raku REPL, when the endpoint of a sequence is a
> Regex, the $/ variable seems not to be set:
> > >
> > > [0] > 1 ... /9/
> > > (1 2 3 4 5 6 7 8 9)
> > > [1] > $/
> > > Nil
> > >
> > > If I match more explicitly using a WhateverCode, it works:
> > >
> > > [2] > 1 ... * ~~ /9/
> > > (1 2 3 4 5 6 7 8 9)
> > > [3] > $/
> > > ｢9｣
> > >
> > > Is this the intended behavior, or a bug?
> > >
> >
>
>

Re: $/ not always set after a regex match?

[Vadim Belman]

I guessed this answer. :) It makes it extra typing and some linenoise. So, I 
wouldn't be really happy about it.

Use of `with` would be less cumbersome, actually. So `with $s ~~ /.../ { 
. }`. Or `$s ~~ /.../ andthen .`. The "extra typing issue" is not 
gone in this case, but the code clarity doesn't suffer.

Best regards,
Vadim Belman

> On Dec 30, 2022, at 5:22 AM, Elizabeth Mattijsen  wrote:
> 
> if $s ~~ /$=[\w+]/ -> $/ { say $ }
> 
>> On 30 Dec 2022, at 03:54, Vadim Belman  wrote:
>> 
>> Optimizations, yes... But then, how could we not use code like `if $s ~~ 
>> /$=[\w+]/ { say $ }`?
>> 
>> Speaking of the subject itself, I don't remember how sequences are actually 
>> implemented in details, but most likely the regex is processed inside the 
>> sequence iterator which owns the $/ used by the regex eventually. 
>> 
>> Best regards,
>> Vadim Belman
>> 
>>> On Dec 28, 2022, at 12:49 PM, Elizabeth Mattijsen  wrote:
>>> 
>>> That's because it at one time was decided that smart-match would set $/ in 
>>> the caller's scope.  Which is a pain for implementation and optimizations.  
>>> I would be very much in favour of getting rid of that "feature", fwiw.
>>> 
 On 28 Dec 2022, at 18:45, Sean McAfee  wrote:
 
 But if a sequence has its own $/, why does * ~~ /9/ set $/?
 
 Actually it's not just sequences, as a little more experimentation showed:
 
 [0] > first /9/, ^Inf
 9
 [1] > $/
 Nil
 [2] > grep /9/, ^10
 (9)
 [3] > $/
 Nil
 
 The * ~~ "trick" sets $/ in these cases too.
 
 
 On Wed, Dec 28, 2022 at 12:01 PM Elizabeth Mattijsen  
 wrote:
 This isn't specific to the REPL:
 
 $ raku -e 'say 1 ... /9/; say $/'
 (1 2 3 4 5 6 7 8 9)
 Nil
 
 I can only assume that the sequence has its own scope for $/, and thus 
 isn't visible outside of it.
 
 
 Liz
 
> On 28 Dec 2022, at 16:47, Sean McAfee  wrote:
> 
> In a fresh 2022.12 Raku REPL, when the endpoint of a sequence is a Regex, 
> the $/ variable seems not to be set:
> 
> [0] > 1 ... /9/
> (1 2 3 4 5 6 7 8 9)
> [1] > $/
> Nil
> 
> If I match more explicitly using a WhateverCode, it works:
> 
> [2] > 1 ... * ~~ /9/
> (1 2 3 4 5 6 7 8 9)
> [3] > $/
> ｢9｣
> 
> Is this the intended behavior, or a bug?
> 
 
>>> 
>> 
> 

Re: $/ not always set after a regex match?

[Elizabeth Mattijsen]

if $s ~~ /$=[\w+]/ -> $/ { say $ }

> On 30 Dec 2022, at 03:54, Vadim Belman  wrote:
> 
> Optimizations, yes... But then, how could we not use code like `if $s ~~ 
> /$=[\w+]/ { say $ }`?
> 
> Speaking of the subject itself, I don't remember how sequences are actually 
> implemented in details, but most likely the regex is processed inside the 
> sequence iterator which owns the $/ used by the regex eventually. 
> 
> Best regards,
> Vadim Belman
> 
>> On Dec 28, 2022, at 12:49 PM, Elizabeth Mattijsen  wrote:
>> 
>> That's because it at one time was decided that smart-match would set $/ in 
>> the caller's scope.  Which is a pain for implementation and optimizations.  
>> I would be very much in favour of getting rid of that "feature", fwiw.
>> 
>>> On 28 Dec 2022, at 18:45, Sean McAfee  wrote:
>>> 
>>> But if a sequence has its own $/, why does * ~~ /9/ set $/?
>>> 
>>> Actually it's not just sequences, as a little more experimentation showed:
>>> 
>>> [0] > first /9/, ^Inf
>>> 9
>>> [1] > $/
>>> Nil
>>> [2] > grep /9/, ^10
>>> (9)
>>> [3] > $/
>>> Nil
>>> 
>>> The * ~~ "trick" sets $/ in these cases too.
>>> 
>>> 
>>> On Wed, Dec 28, 2022 at 12:01 PM Elizabeth Mattijsen  
>>> wrote:
>>> This isn't specific to the REPL:
>>> 
>>> $ raku -e 'say 1 ... /9/; say $/'
>>> (1 2 3 4 5 6 7 8 9)
>>> Nil
>>> 
>>> I can only assume that the sequence has its own scope for $/, and thus 
>>> isn't visible outside of it.
>>> 
>>> 
>>> Liz
>>> 
 On 28 Dec 2022, at 16:47, Sean McAfee  wrote:
 
 In a fresh 2022.12 Raku REPL, when the endpoint of a sequence is a Regex, 
 the $/ variable seems not to be set:
 
 [0] > 1 ... /9/
 (1 2 3 4 5 6 7 8 9)
 [1] > $/
 Nil
 
 If I match more explicitly using a WhateverCode, it works:
 
 [2] > 1 ... * ~~ /9/
 (1 2 3 4 5 6 7 8 9)
 [3] > $/
 ｢9｣
 
 Is this the intended behavior, or a bug?
 
>>> 
>> 
> 

Re: $/ not always set after a regex match?

[Vadim Belman]

Optimizations, yes... But then, how could we not use code like `if $s ~~ 
/$=[\w+]/ { say $ }`?

Speaking of the subject itself, I don't remember how sequences are actually 
implemented in details, but most likely the regex is processed inside the 
sequence iterator which owns the $/ used by the regex eventually. 

Best regards,
Vadim Belman

> On Dec 28, 2022, at 12:49 PM, Elizabeth Mattijsen  wrote:
> 
> That's because it at one time was decided that smart-match would set $/ in 
> the caller's scope.  Which is a pain for implementation and optimizations.  I 
> would be very much in favour of getting rid of that "feature", fwiw.
> 
>> On 28 Dec 2022, at 18:45, Sean McAfee  wrote:
>> 
>> But if a sequence has its own $/, why does * ~~ /9/ set $/?
>> 
>> Actually it's not just sequences, as a little more experimentation showed:
>> 
>> [0] > first /9/, ^Inf
>> 9
>> [1] > $/
>> Nil
>> [2] > grep /9/, ^10
>> (9)
>> [3] > $/
>> Nil
>> 
>> The * ~~ "trick" sets $/ in these cases too.
>> 
>> 
>> On Wed, Dec 28, 2022 at 12:01 PM Elizabeth Mattijsen  wrote:
>> This isn't specific to the REPL:
>> 
>> $ raku -e 'say 1 ... /9/; say $/'
>> (1 2 3 4 5 6 7 8 9)
>> Nil
>> 
>> I can only assume that the sequence has its own scope for $/, and thus isn't 
>> visible outside of it.
>> 
>> 
>> Liz
>> 
>>> On 28 Dec 2022, at 16:47, Sean McAfee  wrote:
>>> 
>>> In a fresh 2022.12 Raku REPL, when the endpoint of a sequence is a Regex, 
>>> the $/ variable seems not to be set:
>>> 
>>> [0] > 1 ... /9/
>>> (1 2 3 4 5 6 7 8 9)
>>> [1] > $/
>>> Nil
>>> 
>>> If I match more explicitly using a WhateverCode, it works:
>>> 
>>> [2] > 1 ... * ~~ /9/
>>> (1 2 3 4 5 6 7 8 9)
>>> [3] > $/
>>> ｢9｣
>>> 
>>> Is this the intended behavior, or a bug?
>>> 
>> 
> 

Re: $/ not always set after a regex match?

[Elizabeth Mattijsen]

Yes, for that code it would have to.

But that code pattern is really from Perl, and predates `with`.

$ raku -e 'say .Str with 9 ~~ /9/'
9

And I think that is what we should be teaching people to use, rather than 
depend on the magic lexical $/.

Liz

> On 28 Dec 2022, at 21:37, William Michels  wrote:
> 
> Doesn't it have to? At least for the following case? 
> 
> [0] > #REPL
> Nil
> [0] > say $/.Str if 9 ~~ /9/;
> 9
> 
> Best regards. --B
> 
> On Wed, Dec 28, 2022, 09:49 Elizabeth Mattijsen  wrote:
> That's because it at one time was decided that smart-match would set $/ in 
> the caller's scope.  Which is a pain for implementation and optimizations.  I 
> would be very much in favour of getting rid of that "feature", fwiw.
> 
>> On 28 Dec 2022, at 18:45, Sean McAfee  wrote:
>> 
>> But if a sequence has its own $/, why does * ~~ /9/ set $/?
>> 
>> Actually it's not just sequences, as a little more experimentation showed:
>> 
>> [0] > first /9/, ^Inf
>> 9
>> [1] > $/
>> Nil
>> [2] > grep /9/, ^10
>> (9)
>> [3] > $/
>> Nil
>> 
>> The * ~~ "trick" sets $/ in these cases too.
>> 
>> 
>> On Wed, Dec 28, 2022 at 12:01 PM Elizabeth Mattijsen  wrote:
>> This isn't specific to the REPL:
>> 
>> $ raku -e 'say 1 ... /9/; say $/'
>> (1 2 3 4 5 6 7 8 9)
>> Nil
>> 
>> I can only assume that the sequence has its own scope for $/, and thus isn't 
>> visible outside of it.
>> 
>> 
>> Liz
>> 
>>> On 28 Dec 2022, at 16:47, Sean McAfee  wrote:
>>> 
>>> In a fresh 2022.12 Raku REPL, when the endpoint of a sequence is a Regex, 
>>> the $/ variable seems not to be set:
>>> 
>>> [0] > 1 ... /9/
>>> (1 2 3 4 5 6 7 8 9)
>>> [1] > $/
>>> Nil
>>> 
>>> If I match more explicitly using a WhateverCode, it works:
>>> 
>>> [2] > 1 ... * ~~ /9/
>>> (1 2 3 4 5 6 7 8 9)
>>> [3] > $/
>>> ｢9｣
>>> 
>>> Is this the intended behavior, or a bug?
>>> 
>> 
> 

Re: $/ not always set after a regex match?

[William Michels via perl6-users]

Doesn't it have to? At least for the following case?

[0] > #REPL
Nil
[0] > say $/.Str if 9 ~~ /9/;
9

Best regards. --B

On Wed, Dec 28, 2022, 09:49 Elizabeth Mattijsen  wrote:

> That's because it at one time was decided that smart-match would set $/ in
> the caller's scope.  Which is a pain for implementation and optimizations.
> I would be very much in favour of getting rid of that "feature", fwiw.
>
> > On 28 Dec 2022, at 18:45, Sean McAfee  wrote:
> >
> > But if a sequence has its own $/, why does * ~~ /9/ set $/?
> >
> > Actually it's not just sequences, as a little more experimentation
> showed:
> >
> > [0] > first /9/, ^Inf
> > 9
> > [1] > $/
> > Nil
> > [2] > grep /9/, ^10
> > (9)
> > [3] > $/
> > Nil
> >
> > The * ~~ "trick" sets $/ in these cases too.
> >
> >
> > On Wed, Dec 28, 2022 at 12:01 PM Elizabeth Mattijsen 
> wrote:
> > This isn't specific to the REPL:
> >
> > $ raku -e 'say 1 ... /9/; say $/'
> > (1 2 3 4 5 6 7 8 9)
> > Nil
> >
> > I can only assume that the sequence has its own scope for $/, and thus
> isn't visible outside of it.
> >
> >
> > Liz
> >
> > > On 28 Dec 2022, at 16:47, Sean McAfee  wrote:
> > >
> > > In a fresh 2022.12 Raku REPL, when the endpoint of a sequence is a
> Regex, the $/ variable seems not to be set:
> > >
> > > [0] > 1 ... /9/
> > > (1 2 3 4 5 6 7 8 9)
> > > [1] > $/
> > > Nil
> > >
> > > If I match more explicitly using a WhateverCode, it works:
> > >
> > > [2] > 1 ... * ~~ /9/
> > > (1 2 3 4 5 6 7 8 9)
> > > [3] > $/
> > > ｢9｣
> > >
> > > Is this the intended behavior, or a bug?
> > >
> >
>
>

Re: $/ not always set after a regex match?

[Elizabeth Mattijsen]

That's because it at one time was decided that smart-match would set $/ in the 
caller's scope.  Which is a pain for implementation and optimizations.  I would 
be very much in favour of getting rid of that "feature", fwiw.

> On 28 Dec 2022, at 18:45, Sean McAfee  wrote:
> 
> But if a sequence has its own $/, why does * ~~ /9/ set $/?
> 
> Actually it's not just sequences, as a little more experimentation showed:
> 
> [0] > first /9/, ^Inf
> 9
> [1] > $/
> Nil
> [2] > grep /9/, ^10
> (9)
> [3] > $/
> Nil
> 
> The * ~~ "trick" sets $/ in these cases too.
> 
> 
> On Wed, Dec 28, 2022 at 12:01 PM Elizabeth Mattijsen  wrote:
> This isn't specific to the REPL:
> 
> $ raku -e 'say 1 ... /9/; say $/'
> (1 2 3 4 5 6 7 8 9)
> Nil
> 
> I can only assume that the sequence has its own scope for $/, and thus isn't 
> visible outside of it.
> 
> 
> Liz
> 
> > On 28 Dec 2022, at 16:47, Sean McAfee  wrote:
> > 
> > In a fresh 2022.12 Raku REPL, when the endpoint of a sequence is a Regex, 
> > the $/ variable seems not to be set:
> > 
> > [0] > 1 ... /9/
> > (1 2 3 4 5 6 7 8 9)
> > [1] > $/
> > Nil
> > 
> > If I match more explicitly using a WhateverCode, it works:
> > 
> > [2] > 1 ... * ~~ /9/
> > (1 2 3 4 5 6 7 8 9)
> > [3] > $/
> > ｢9｣
> > 
> > Is this the intended behavior, or a bug?
> > 
> 

Re: $/ not always set after a regex match?

[Sean McAfee]

But if a sequence has its own $/, why does * ~~ /9/ set $/?

Actually it's not just sequences, as a little more experimentation showed:

[0] > first /9/, ^Inf
9
[1] > $/
Nil
[2] > grep /9/, ^10
(9)
[3] > $/
Nil

The * ~~ "trick" sets $/ in these cases too.


On Wed, Dec 28, 2022 at 12:01 PM Elizabeth Mattijsen  wrote:

> This isn't specific to the REPL:
>
> $ raku -e 'say 1 ... /9/; say $/'
> (1 2 3 4 5 6 7 8 9)
> Nil
>
> I can only assume that the sequence has its own scope for $/, and thus
> isn't visible outside of it.
>
>
> Liz
>
> > On 28 Dec 2022, at 16:47, Sean McAfee  wrote:
> >
> > In a fresh 2022.12 Raku REPL, when the endpoint of a sequence is a
> Regex, the $/ variable seems not to be set:
> >
> > [0] > 1 ... /9/
> > (1 2 3 4 5 6 7 8 9)
> > [1] > $/
> > Nil
> >
> > If I match more explicitly using a WhateverCode, it works:
> >
> > [2] > 1 ... * ~~ /9/
> > (1 2 3 4 5 6 7 8 9)
> > [3] > $/
> > ｢9｣
> >
> > Is this the intended behavior, or a bug?
> >
>
>

Re: $/ not always set after a regex match?

[Elizabeth Mattijsen]

This isn't specific to the REPL:

$ raku -e 'say 1 ... /9/; say $/'
(1 2 3 4 5 6 7 8 9)
Nil

I can only assume that the sequence has its own scope for $/, and thus isn't 
visible outside of it.


Liz

> On 28 Dec 2022, at 16:47, Sean McAfee  wrote:
> 
> In a fresh 2022.12 Raku REPL, when the endpoint of a sequence is a Regex, the 
> $/ variable seems not to be set:
> 
> [0] > 1 ... /9/
> (1 2 3 4 5 6 7 8 9)
> [1] > $/
> Nil
> 
> If I match more explicitly using a WhateverCode, it works:
> 
> [2] > 1 ... * ~~ /9/
> (1 2 3 4 5 6 7 8 9)
> [3] > $/
> ｢9｣
> 
> Is this the intended behavior, or a bug?
> 

$/ not always set after a regex match?

[Sean McAfee]

In a fresh 2022.12 Raku REPL, when the endpoint of a sequence is a Regex,
the $/ variable seems not to be set:

[0] > 1 ... /9/
(1 2 3 4 5 6 7 8 9)
[1] > $/
Nil

If I match more explicitly using a WhateverCode, it works:

[2] > 1 ... * ~~ /9/
(1 2 3 4 5 6 7 8 9)
[3] > $/
｢9｣

Is this the intended behavior, or a bug?