2 Jun 2026
[Coke] anyone know who has privs on dev.azure.com/MoarVM/MoarVM/ ? 01:18
I can see the runs, but if I try to rerun failed ones, I get TF400813: The user 'edb5f846-d424-4534-aab5-b9a3282ae013' is not authorized to access this resource.
ah. looks like I'm in Raku/nqp on azure.com, but not MoarVM/MoarVM - can someone with rights add me, please? 01:24
Geth rakudo/main: 6 commits pushed by (Nick Logan)++ 01:50
rakudo: ugexe++ created pull request #6217:
RakuAST: fix sub signature parameter and parametric role compile crashes
02:58
rakudo: ugexe++ created pull request #6218:
RakuAST: emit empty concat for modifier-only alternation branch
04:04
lizmat ugexe++ 08:29
sometimes I wonder whether it would make sense to make a $*RESOLVER and $*CONTEXT dynvar instead of keeping passing them around 08:30
Geth roast: ba1e02a602 | (Elizabeth Mattijsen)++ | S06-currying/misc.t
Add tests for github.com/rakudo/rakudo/issues/6212
08:43
roast: 867b9869f7 | (Elizabeth Mattijsen)++ | 4 files
Untodo now passing .assuming tests

Since the RakuAST based .assuming implementation made it to the 2026.05 release, it's time to make these tests canonical
09:09
ab5tract From a grammar standpoint, would it be possible to support 'do' in postfix statements? 12:08
m: with True do say "I'd like this" 12:09
camelia ===SORRY!=== Error while compiling <tmp>
Missing block
at <tmp>:1
------> with True<HERE> do say "I'd like this"
expecting any of:
block or pointy block
infix
infix stopper
ab5tract oops, not postfix statements at all. This is in place of the regular block form, as opposed to the postfix statements. 12:11
m: with $maybe do .definitely 12:12
camelia ===SORRY!=== Error while compiling <tmp>
Variable '$maybe' is not declared. Perhaps you forgot a 'sub' if this
was intended to be part of a signature?
at <tmp>:1
------> with <HERE>$maybe do .definitely
ab5tract crucially, we'd want the auto-topicalization behavior that makes postfix so useful. 12:14
For my taste, postfix works great for if/unless. but I really struggle to enjoy it with 'for' and 'with' 12:15
`for @foo do .frob` feels like it might be a nice compromise, assuming that it is even possible 12:16
lizmat .definitely with $maybe 12:28
what's wrong with that ?
not sure what you want to achieve :-) 12:29
ab5tract I don't like that syntax 12:49
.definitely unless maybe # makes sense as a sequence of words
.definitely for maybe # does not 12:50
This is a personal thing. I was just trying to gauge whether it is even possible. 12:51
lizmat m: sub do($a) { $a }; do .say with 42 12:52
camelia 42
ab5tract lizmat: that's not the same thing though
that's using postfix with still 12:53
I am simply suggesting that do be allowed to stand in for a block and have auto-topicalization while doing so
if $wrong do make-it-right 12:54
if $wrong do .&make-it-right
And suggesting might even be too strong a word. My intent is mostly to see if there's any interest beyond myself and to gauge difficulty, if possible. 12:56
ShimmerFairy I don't see why `with 42 { .say }` wouldn't suffice. I get that it's aesthetically different from having an english word, but the braces use the same number of meaningful characters, and works with the language as-is (whereas 'do' in this manner would be a new syntax, just for this feature). 13:08
librasteve_ i kinda like it from a user pov (can’t speak to the difficulty), I like `.say for ^3` and `.say with $x` but would be happy to see `for ^3 do .say` timtowdi wise 13:17
ab5tract Looking at it more, it does look like 'do' would be adding a sepcial semantics for this case, which makes me like the idea a lot less 14:41
lizmat it would also make error reporting on improper use of "do" a lot more difficult :-( 14:45
ab5tract okay, this is more for the fun of thinking about it than anything else, but maybe pointy arrow could have the desired semantics when used without a signature *or* a block. It could take a single expression and have -> ($_) as the signature 15:16
for @all -> .say
lizmat I don't see the advantage above: .say for @all 15:46
ab5tract Again, I really don't like that syntax and rarely use it. Something about the bare method call and the out of order language use 16:01
for @all { .say } is fine. I am also trying to discuss the capabilities of the grammar here, is this feasible, let's have a discussion, etc\ 16:02
*the bare method call starting off the statement list 16:05