00:02 dg left 00:03 librasteve_ left 00:05 kaskal left, kaskal joined 00:13 dg joined 00:25 ACfromTX left 00:27 kjp left 00:28 kjp joined 00:30 kjp left 00:31 kjp joined 00:54 dg left 01:00 dg joined 01:12 vrurg joined, vrurg_ left 01:32 zetaaaa joined 01:37 dgl joined 01:40 dg left, dgl is now known as dg 01:49 hulk joined 01:50 kylese left 01:56 kylese joined 01:57 vrurg_ joined, hulk left, vrurg left, kaskal left 01:58 kaskal joined, kjp left 01:59 kjp joined 02:15 kylese left, kylese joined 02:42 arkiuat left 02:45 zetaaaa left 02:48 arkiuat joined 02:53 arkiuat left 02:54 arkiuat joined 02:59 arkiuat left 03:08 arkiuat joined 03:17 ACfromTX joined 03:19 dg left 03:25 dg joined 03:43 dgl joined 03:48 dg left, dgl left 03:52 dg joined 03:59 stanrifkin_ joined 04:01 stanrifkin left 04:25 dg left 04:30 dg joined 04:34 dg left 04:44 dg joined 05:12 Aedil joined 05:19 dgl joined 05:23 dg left, dgl is now known as dg 05:35 arkiuat left 05:37 arkiuat joined 05:45 arkiuat left 05:55 dg left 05:59 arkiuat joined, kylese left 06:00 dg joined, kylese joined 06:03 arkiuat left 06:33 arkiuat joined 06:38 arkiuat left 06:54 Sgeo left 07:09 arkiuat joined 07:13 arkiuat left 07:20 abraxxa joined 07:33 arkiuat joined 07:35 librasteve_ joined 07:38 arkiuat left 07:51 arkiuat joined
disbot5 <simon_sibl> is there an "easy" way in Raku to loop through an array indefinitely ? for example [1,2,3] to yield [1,2,3,1,2,3,1,2,3,1,2,3...] 07:54
07:56 arkiuat left
disbot5 <nahita3882> m: (|[1, 2, 3] xx *).head(10).say 07:59
<nahita3882> > (1 2 3 1 2 3 1 2 3 1) 08:00
<nahita3882> so for |[1, 2, 3] xx * {...}
<nahita3882> infinitely repeat the list and slip the contents to get flat 1, 2, 3, 1... stream 08:01
<nahita3882> there is also third-party &Iter::Able::cycle with self-promotion
<nahita3882> for cycle([1, 2, 3]) { ... } 08:02
<nahita3882> interestingly the number of characters is the same in both if you do a parenthesesless call in the latter 08:04
<simon_sibl> I dont see cycle sub anywhere, is it new ? 08:05
<simon_sibl> oh third party my bad 08:06
<simon_sibl> I like the |[1,2,3] xx *, thanks !
lizmat actually, |(1,2,3) xx * should marginally be more performant
08:15 dakkar joined 08:18 arkiuat joined 08:23 arkiuat left 08:50 arkiuat joined 08:54 arkiuat left 08:56 stanrifkin_ left 09:07 melezhik_ joined
melezhik_ . 09:08
09:15 melezhik_ left, melezhik_ joined 09:16 melezhik_ left 09:19 arkiuat joined 09:24 arkiuat left
disbot5 <librasteve> o/ 09:40
<librasteve> I am working on a proposal for Raku devroom participation at Fosdem 2026 ... depending on the time allocated we need 6 or 8 talks and, while the formal request for papers will happen if and when the room is granted, I would like to be able to position some of the topics that we can offer in the submission (due on Sunday 12th) 09:42
<librasteve> The twenty-sixth edition will take place on Saturday 31st January and Sunday 1st February 2026 at the usual location, ULB Campus Solbosch in Brussels. This is a face to face event. And we are inviting speakers to come at your own expense. 09:43
<librasteve> Please PM me (librasteve@furnival.net) if you are interested - ideally with a draft title and very short summary. 09:44
09:52 arkiuat joined 09:57 arkiuat left 10:06 apac joined 10:20 arkiuat joined 10:25 arkiuat left 10:52 arkiuat joined 10:56 arkiuat left
ds7832 I'm trying to understand what the double semicolon does in multi signatures (docs.raku.org/language/signatures#Long_names): "exclude certain parameters from being considered in multiple dispatch" — From some trials it looks like this means that signatures with parameters after a double semicolon are "as narrow" as signatures without those parameters. Is that right? 11:00
ab5tract Looking at that example does not give much clarity. It uses a named param `:$b`, which would have dispatched exactly the same without `;;` 11:08
ds7832 I thought so too - just until now
m: multi e(Int $i) { say "just $i" }; multi e(Int $i, Str :$s) { say "both $i and $s" }; e(42) 11:09
camelia Use of uninitialized value of type Str in string context.
Methods .^name, .raku, .gist, or .say can be used to stringify it to something meaningful.
both 42 and
in sub e at <tmp> line 1
ds7832 Whereas with ;; we get
m: multi e(Int $i) { say "just $i" }; multi e(Int $i;; Str :$s) { say "both $i and $s" }; e(42)
camelia Ambiguous call to 'e(Int)'; these signatures all match:
(Int $i) from <tmp> line 1
(Int $i;; Str :$s) from <tmp> line 1
in block <unit> at <tmp> line 1
ds7832 So in the first example what's going on is that the signature with $s is considered narrower than that with just 42 (fair enough), *and* it actually matches in the call e(42), but I don't recall exactly why that is 11:13
So it seems that ;; reduces the "narrowness", and thus the precedence, of the signature, down to the level it would have if those parameters weren't present at all 11:20
11:21 arkiuat joined
ds7832 However that interpretation of ;; is not fully consistent with another experiment: 11:23
m: multi f(Int $a, Int $b;; Int $c){ say "would be narrower" }; multi f(Int $a;; Int $b, Int $c){ say "but this is considered equally narrow" }; f(1,2,3) 11:24
camelia Ambiguous call to 'f(Int, Int, Int)'; these signatures all match:
(Int $a, Int $b;; Int $c) from <tmp> line 1
(Int $a;; Int $b, Int $c) from <tmp> line 1
in block <unit> at <tmp> line 1
ds7832 It apparently does work in the described way though if all parameters after ;; are named parameters. 11:26
11:26 arkiuat left
ds7832 m: multi f(Int $a, Int :$b;; Int :$c){ say "more narrow" }; multi f(Int $a;; Int :$b, Int: $c){ say "less narrow" }; f(1,2,3) 11:27
camelia ===SORRY!=== Error while compiling <tmp>
Cannot put required parameter after named parameters
at <tmp>:1
------> arrow" }; multi f(Int $a;; Int :$b, Int:<HERE> $c){ say "less narrow" }; f(1,2,3)
expecting any of:
formal paramete…
ds7832 Uh, ignore that. This is what I meant:
m: multi f(Int $a, Int :$b;; Int :$c){ say "more narrow" }; multi f(Int $a;; Int :$b, Int :$c){ say "less narrow" }; f(1,:2b,:3c) 11:28
camelia more narrow
ds7832 The difference being that the first one (with "more narrow") has the parameter :$b before the double semicolon. 11:29
Also in line with that: If in any of the above examples that threw "Ambiguous call" one adds the trait "is default" to either one of the multi definition, this definition then takes precedence. This actually seems like one of the most important use cases for ;; 11:46
11:55 arkiuat joined 12:00 arkiuat left
ab5tract ds7832: would you consider adding any examples / clarifications you've gotten to the docs? 12:10
ds7832 Definitely, I'm writing on it :) 12:11
12:22 arkiuat joined 12:26 arkiuat left 12:44 arkiuat joined
arkiuat Now I'm wondering where and how the behavior of the double-semicolon ;; is tested in roast 12:55
To distinguish the language spec that should be documented from what might be unspecified implementation detail 12:56
disbot5 <librasteve> appreciate the help in ironing out this corner of the docs ... at first look at this section I am mystified why it is headed "Long Names" - I for one would be happy to change that, plus the example imo would be better with multiple multis to show both narrow and broad as you show ^^ 13:00
13:04 apac left 13:09 apac joined
ds7832 arkiuat: Good question. Part of it here: github.com/Raku/roast/blob/master/...invocant.t -- i.e. the last two tests. Especially the last one indicates that there are different types of parameters, "positional multi" for positionals before ;;, and just "positional" for those after ;;. So it's most likely that only "positional multi"s contribute to determining the precedence of multi, and that that's what' 13:23
s behind the current phrasing in the docs.
"multi-invocant" seems to be the technical name 13:24
arkiuat ds7832, thanks! (both for finding that for me and for all the great work you've been doing on the docs lately) 13:25
ds7832 makes me happy to hear that! The work on the docs is also a good way to learn 13:26
arkiuat yes it is! 13:28
for this bit, it would be helpful if you could refer to the doc for the .multi-invocant method, which belongs to class Parameter but hasn't been added yet (unless you just added it recently) 13:34
and I never would have known about the .multi-invocant method without looking at roast, because it's not mentioned anywhere in the docs.raku.org/language/signatures doc that you're working on 13:36
and the double-semicolons probably need to be at least mentioned in the "Parameter seperators" section up near the top of that doc you're working on 13:42
I'd add that myself but I wouldn't want to collide; maybe I'll add method .multi-invocant to class Parameter 13:44
ds7832 The top section, I already plan to put slurpies in there. That'll make it already quite long, so I'm mulling keeping the more advanced and less-needed things out of there: the "invocant marker" can probably just live in its own section (which comes right thereafter), and I think the ;; too is difficult to explain and at the same time seldom needed, much less than e.g. the required/optional markers ! and ? 13:48
13:49 m6locks left
ds7832 which are good, intuitive, less-technical-to-explain alternatives for it, so I think it's good to have ;; far down at the bottom 13:49
(yeah, that's good to avoid git collisions, thanks) 13:50
arkiuat I literally meant that it just ought to be mentioned: a section labeled "Parameter separators" ought to at least mention all the possibilities. Like "For semicolon separators, see [[your-section-reference-here]] below." 13:52
I've started on my fork to add .multi-invocant to class Parameter's docs 13:53
ds7832 Ah, in the section "Parameter separators", sorry I misunderstood. Yeah, it should be mentioned there 14:02
14:08 apac left 14:17 apac joined
arkiuat .tell tbrowder thanks for that Contributing-PRs.md doc of yours! I left a suggestion for you about it over on #raku-doc 14:39
hmm, is tellable offline?
disbot5 <librasteve> lemme try 14:40
14:40 guifa left 14:41 guifa joined
librasteve_ .tell arkuiat hello 14:43
.seen jnthn
m: say 0.1+0.2
camelia 0.3
14:44 apac left
librasteve_ tall: arkuiat hello 14:44
tell: arkuiat hello
looks like some of the bots are offline...
14:55 dg left 14:57 apac joined
tbrowder is there any magic way to parameterizs sub returns? i know this doesn't work: --> List of Str 15:01
m: sub F(--> List of Str) { my @w = "a", "b"; } 15:04
camelia ===SORRY!=== Error while compiling <tmp>
List cannot be parameterized
at <tmp>:1
------> sub F(--> List of Str<HERE>) { my @w = "a", "b"; }
librasteve_ m: sub fn(--> Array[Str]()) { <a b> }; say fn(); 15:09
camelia [a b]
librasteve_ tbrowder: a couple of things going on here (i) if you want to have a Positional that polices the types of its elements, then Array[Str] or Array[Int] can do that, while List does not have that power and (ii) then you can either be explicit in your code that you are making one of these, or you can apply the extra parens () to coerce your values into the desired type as in my example 15:11
15:12 arkiuat left
Voldenet coercing from Array to Array[Str] costs so it's cheaper to simply start with Array[Str] if possible 15:13
disbot5 <librasteve> well yes, but if speed is what you want then I suggest golang 15:14
<librasteve> or rust
Voldenet m: sub F(–> Array[Str]) { my Str @w = "a", "b" }; say F() # not overly verbose
camelia ===SORRY!=== Error while compiling <tmp>
Missing block
at <tmp>:1
------> sub F(<HERE>–> Array[Str]) { my Str @w = "a", "b" };
disbot5 <librasteve> ;-)
Voldenet m: sub F(--> Array[Str]) { my Str @w = "a", "b" }; say F() # not overly verbose/
camelia [a b]
disbot5 <librasteve> timtowdi 15:15
Voldenet but why pay more if you can pay less
it's still a tradeoff
disbot5 <librasteve> now if this was Python we could spend a couple of hours telling each other they are wrong 15:17
Voldenet ridiculous I could pull a benchmark ;p
disbot5 <librasteve> what about the zen dude 15:18
15:20 human-blip left
Voldenet ngl it's more significant than I thought 0x0.st/Ku1u.raku 15:21
and with only 2-element array
what I'm benchmarking is ram though, it's pointless 15:22
15:22 human-blip joined
Voldenet I agree that I'd pick the coercing syntax if I had to pick one myself 15:23
other version feels redundant and it makes my head itch wrong
15:24 arkiuat joined
Voldenet in the perfect world the compiler could easily say that @w gets returned and nothing uses this copy, so it could avoid allocation… ;) 15:24
15:28 arkiuat left 15:43 arkiuat joined 15:46 snonux left 15:48 arkiuat left, snonux joined 15:50 arkiuat joined 16:10 apac left 16:37 dakkar left 17:17 stanrifkin joined
tonyo . 17:21
tbrowder thnx gang 17:47
17:57 melezhik joined 18:35 librasteve_ left 18:43 AntonOks joined, arkiuat left 18:50 arkiuat joined 18:54 AntonOks left, arkiuat left 19:07 arkiuat joined 19:12 arkiuat left 19:29 apac joined 19:31 arkiuat joined 19:37 snonux left 19:38 snonux joined 20:07 melezhik left 20:30 kylese left 20:45 sourceable6 left, nativecallable6 left, notable6__ left, benchable6 left, greppable6 left, unicodable6 left, evalable6 left, committable6 left 20:48 evalable6 joined, unicodable6 joined, linkable6 joined, bloatable6 joined, benchable6 joined 20:49 bisectable6 joined, tellable6 joined, greppable6 joined, releasable6 joined, coverable6 joined, shareable6 joined, notable6 joined, quotable6 joined, nativecallable6 joined 20:50 committable6 joined, sourceable6 joined 21:58 stanrifkin left 22:43 zetaaaa joined 23:25 apac left 23:44 Sgeo joined 23:55 Aedil left

Powered by Cro and the Raku® Programming Language.

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

Thank you!