Optimizations, yes... But then, how could we not use code like `if $s ~~
/$<word>=[\w+]/ { say $<word> }`?
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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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?
>>>
>>
>
