02:05 frost joined
frost hello 03:33
m: my $sig = :($a); say 1 ~~ $sig;
camelia False
frost m: my $sig = :($a, $b); say (1,2) ~~ $sig;
camelia True
frost m: my $sig = :($a); say (1,( ~~ $sig; 03:34
camelia ===SORRY!=== Error while compiling <tmp>
Expected a term, but found either infix ~~ or redundant prefix ~
(to suppress this message, please use a space like ~ ~)
at <tmp>:1
------> my $sig = :($a); say (1,( ~~⏏ $sig;
frost m: my $sig = :($a); say (1,) ~~ $sig;
camelia True
frost can I only match one value 1 rather than a list (1,) ? 03:35
CIAvash frost: I don't think so, you're matching against a signature, so it has to be a list of positionals and/or named parameters, unless you use a capture 06:15
m: say \(1) ~~ :($a)
camelia True
frost CIAvash: Thanks! 08:48
Nemokosch Is there a way to cut a sequence at the first repetition? 11:49
like some greedy uniq
wamba m: 12:02
```
1, {1+1/$_ } ... * =~= * andthen .say
```
m: 1, {1+1/$_ } ... * =~= * andthen .say
m: `1, {1+1/$_ } ... * =~= * andthen .say`
Nemokosch hm no, not like this, perhaps I wasn't clear enough 12:10
the repetition doesn't have to happen for neighborous elements
so, say, 3, 2, 1, 2, 8, 1, 6, 2, 1, 3, .. should stop at 3, 2, 1 12:12
12:14 discord-raku-bot left 12:15 discord-raku-bot joined
lizmat Nemokosch: you can use "last" in a grep or a map 12:18
12:19 discord-raku-bot left, discord-raku-bot joined
lizmat m: my %seen; dd (1,2,3,4,5,1,6,7).grep: { %seen{$_}++ ?? (last) !! True } 12:22
camelia (1, 2, 3, 4, 5).Seq
Nemokosch oh, so can it outlast the block?
wamba m: 3, 2, 1, 2, 8, 1, 6, 2, 1, 3 andthen [\,] $_ andthen .toggle: !*.repeated andthen .tail.say
Nemokosch do you think this could work for a sequence? 12:24
lizmat .grep works on anything sequency 12:25
m: my %seen; dd (1,2,3,4,5,1,6,7).map(* ** 2).grep: { %seen{$_}++ ?? (last) !! True }
camelia (1, 4, 9, 16, 25).Seq
wamba m: { (^10).pick } ... * andthen [\,] $_ andthen .toggle: !*.repeated andthen .tail.say 12:27
Nemokosch I suppose the irc bridge cannot take dc replies into account; that question was directed to wamba
hmmm
is toggle like the flipflop operator? 12:29
I'm curious about how this works... 12:33
Liz's solution is already better than what I knew but this... what the hell 😄
that is a produce metaoperator, right? 12:37
just discord ate it
wamba yes
Nemokosch oh right, makes sense 12:39
it looks nicer, although the other one with the explicit hash should be more resource effective
for my own particular case, that's not a serious concern 😛
lizmat Nemokosch: just showing that you can use "last" (and "next" actually) in a .map or .grep 12:40
Nemokosch that's definitely good to know, thank you 12:43
are blocks really just like inline blocks, with the same scoping and control flow?
12:45 discord-raku-bot left 12:46 discord-raku-bot joined
lizmat Nemokosch: they're all blocks 12:47
m: my $block = { .say }; $block("foo")
camelia foo 12:48
lizmat m: my $block = -> $text { $text.say }; $block("foo")
camelia foo
lizmat m: if "foo" -> $text { $text.say }
camelia foo
lizmat they're all basically the same thing
m: my $block = *.say; $block("foo") 12:49
camelia foo
Nemokosch so they are transparent to anything a usual block would be 12:51
however you can't use recursion with them, or can you?
> Cannot use samewith outside of a routine 12:58
13:01 discord-raku-bot left, discord-raku-bot joined
lizmat indeed, that needs a sub :-) 13:03
Nemokosch okay, it's coming along... 13:10
one last question: in the light of this, what is the lifecycle of state variables? 13:12
gfldex They exists once per routine and thread. 13:13
lizmat I think technically it's called "once per capture clone"
and, fwiw, I would advise against using state variables in anything multi-thready 13:14
as state variables still have a race condition :-(
(if I remember correctly, it's been a while since I looked at that) 13:15
gfldex m:``` 13:16
my &s1 = sub { state $i; say $i++ };
s1;
my &s2 = &s1.clone;
s2;
```
m:``` 13:18
my &s1 = sub { state $i; say $i++ };
s1;
&s1.wrap(sub { nextsame });
s1;
```
Nemokosch what if a state variable is contained by a block?
gfldex It is best to assume that all blocks are inlined.
That `.wrap` resets state vars is an ENODOC. 13:19
lizmat .wrap introduces another scope, so no surprise in my understanding 13:20
Nemokosch blocks do limit the access scope though, right? 13:21
they aren't some funky dynamic var makers 13:22
gfldex blocks create a scope 13:27
Nemokosch What I'm trying to understand is the lifecycle of a scoped state variable 13:30
is it like a variable of the outer scope?
14:21 frost left 15:10 jgaz joined 15:12 jgaz left
gfldex Visibility and lifetime is not the same thing. 16:57
Nemokosch Yes, I know, that's why I ask about both separately
19:32 discord-raku-bot left, discord-raku-bot joined 19:38 MasterDuke left 19:46 MasterDuke joined
Rogue it's visible only in the scope in which it is declared but in terms of lifetime it's as if you declared it exactly one scope out from that 21:30
m: ```
for 1..2 {
for 1..2 {
state $i;
say $i++;
}
}```
and that's static scope afaik, not dynamic 21:32
oh I see
we're wondering about wrapped routines here
To my understanding, the wrapped version is not considered the same subroutine as the original, so it gets a newly-created set of storage locations for those state variables 21:35
in the same way that the following two subroutines would have different stores for their state variables: 21:36
```
sub a { state $i; }
sub b { state $i; }```
that behavior might be less-than-awesome because, naïvely, one would not expect wrapping a subroutine to "reset" anything 21:37
but it does make sense
from an implementation perspective 21:38

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!