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 Be
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 an
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, ro
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 different
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]
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 b
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
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
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 sin
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 doe
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
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
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
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
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
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 Elizabe
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 endpoi
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 b
18 matches
Mail list logo