🦋 Welcome to the MAIN() IRC channel of the Raku Programming Language (raku.org). Log available at irclogs.raku.org/raku/live.html . If you're a beginner, you can also check out the #raku-beginner channel!
Set by lizmat on 6 September 2022.
ab5tract_ codesections: Another approach to tickets that are fixed in RakuAST is to leave them open until the release actually happens. This way users that encounter the same behavior in the base compiler will be less likely to accidentally open a duplicate ticket. 08:02
lizmat fwiw, that's how I envisioned the use of the "fixed in RakuAST" label 09:33
nemokosch same ^^ 09:39
codesections O.o it didn't occur to me that users would be likely to limit their search to open issues! But yeah, that makes sense 09:50
lizmat that's the default setting fwiw
ab5tract_ Nemokosch: I think your confusion over the fixed-ness of 5239 is because it was working for `* ~~ $_` and a few other cases. 10:14
The fix for getting it working universally was actually a 5 minute change :) 10:15
probably less time, actually
nemokosch What I can remember is that you could get false negatives if you didn't set the topic at all 10:21
oh... * ~~ $_ is whatevercode 10:22
ab5tract_ right, which we determined was working a week or so ago
nemokosch right, this works in RakuAST and not in the old frontend 10:23
(* ~~ $_)(10) will get you True and previously it said False
ab5tract_ and now I've got the behavior in 5239 fixed too
nemokosch oh really? what was it?
ab5tract_ pushing now, one sec 10:24
lizmat: another ticket that can get "Fixed in RakuAST" attached -- github.com/rakudo/rakudo/issues/53...1758068696
lizmat done 10:25
ab5tract_ nemokosch: github.com/rakudo/rakudo/pull/5411 10:27
it looks like a classic thinko
nemokosch I think the idea with "Fixed in RakuAST" was mainly three things: 1. to show that there is progress on the issue 2. to show developers that it's not the end of the world to not fix it in the old system if it seems complicated 3. to give some "regression tests" to RakuAST when it's ready 10:28
I'm trying to comprehend this code - well, it's not easy 10:34
ab5tract_ oh :( 10:35
basically when the compiler calls that `IMPL-COMPILE-QAST` hook on a `RakuAST::Infix` node, by default we give it the QAST to call the `:infix<<$!operator>>` of that node 10:38
the behavior of that operator is defined elsewhere, on the other side of the compiler (ie, base behavior) 10:39
ab5tract_ we already had a guard that says "if not a RakuAST::Var, instead compile my specialized QAST via IMPL-SMARTMATCH-QAST" 10:41
which is why `12 ~~ { $_ == 12}` works as expected even without this patch
nemokosch I don't quite remember but there were operators that really turned into QAST-level method calls, rather than calling a subroutine
ab5tract_ and may have contributed to the confusion that this was already fixed
nemokosch > Handle cases of s/// or m// separately. For a non-negating smartmatch this case could've been reduced to plain topic localization except that we must ensure a False returned when there is no match. 10:45
this is great news in its way
ab5tract_ yes, any operator can override some `IMPL-*` hooks and provide a different QAST tree to the backend. which is actually what my code does: generate the QAST to temporarize the topic variable and call accepts on the RHS
nemokosch I'd really like these "smartmatches" to be completely different from the usual ACCEPTS way 10:46
ab5tract_ you could probably replace it with the QAST to just call equality on it 10:47
nemokosch because they served as the reason matches couldn't be meaningfully smartmatched
smartmatch of matches had to always, unconditionally return the right handside 10:48
in order to make these two special cases work
ab5tract_ Re: the equality thing I was thinking of how my patch special cases `<foo> ~~ $_`, which should probably almost always be true. But actually I believe we want to keep the `ACCEPTS` behavior here because someone may have overridden that method to do something exceptional. 10:55
nemokosch: is there already a ticket for the match smartmatch misbehavior? 10:57
nemokosch I don't think so. It was more or less the natural consequence of "welcoming" m// and s/// to the smartmatches, I talked a lot about how I don't like it but it would have been weird to call it a "bug" 10:58
m: say 1 ~~ 'almafa'.match(/a./) 11:06
evalable6 ｢al｣
Raku eval ｢al｣
nemokosch this is "the ticket" 😄
I think actually an array of matches is also special cased, for a similar reason 11:07
here is an example of an internal "magic" method being called: user-images.githubusercontent.com/...e9b823.png 11:09
dispatch:<var>
ab5tract_ I've never really run into this in the wild 11:48
I wonder if things could be cleaned up a bit there though, without hurting anything
tonyo . 17:34
jdv , 17:35
El_Che ;
I win!

Powered by Cro and the Raku® Programming Language.

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

Thank you!