Re: $/ not always set after a regex match?
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?
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?
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?
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?
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?
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?
>>>
>>
>
