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

2023-01-02 Thread 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

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

2023-01-02 Thread 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

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

2022-12-31 Thread 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,

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

2022-12-31 Thread 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.

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

2022-12-30 Thread 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

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

2022-12-30 Thread 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?

2022-12-30 Thread 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.

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

2022-12-30 Thread 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

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

2022-12-30 Thread 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

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

2022-12-30 Thread 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,

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

2022-12-29 Thread 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

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

2022-12-28 Thread 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

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

2022-12-28 Thread 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

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

2022-12-28 Thread 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

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

2022-12-28 Thread 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

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

2022-12-28 Thread 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