"In general, the left side of `~~` should not be auto-threading"

[raiph]

In general, the left side of ~~ should not be auto-threading

Larry Wall, from https://www.nntp.perl.org/group/perl.perl6.users/2021/06/msg9966.html in May.

This seems like a very serious issue.

Please read Larry's two comments, taking on board the ramifications he outlines for both optimization and correctness/craziness if we let the LHS of ~~ autothread.

---

Update I should have qualified that last sentence with "if the RHS is not a type object". Instead I did effectively the opposite, writing the following misleading comment, which I've struck out to reduce further confusion:

And then consider this extremely popular (wrong!?!) idiom:

where .all ~~ Foo

(which I recently discovered doesn't work for a lot of cases I hoped it would work for.)

In summary this issue was intended to be "just" about Larry's comments, treating them with the respect their due, and considering how to respond to them to fix existing problems in Rakudo hinted at in the email thread to which Larry contributed.

(Thanks to codesections for his first comment which brought my attention to the fact that Larry had specifically enabled the .all ~~ Foo idiom in 2015 and I now realize it looks like he was not arguing in his comments this year that it should be deprecated -- even if the outcome of this issue is that it does actually end up being deprecated in 6.e.)

[lizmat]

It appears I already created an exception to handle this in 2019 rakudo/rakudo@b5d529c7e9 but it appears not to actually be in use.

[lizmat]

Also related: rakudo/rakudo#3849

[lizmat]

Whatever we decide to do, I think we will need to make that a language level change, so most likely deprecate it now for 6.e, and disallow altogether in a future version.

Some research shows that we need to decide:

1. do we only disallow left-hand side of ~~, or do we only throw on the .ACCEPT(Junction:D)? The latter would perhaps mean a less clear error message, or we just need to mention "smartmatching".
2. What do we recommend users as an alternative??

In any case, dieing in either a special infix:<~~>(Junction:D, ...) candidate, or in a method ACCEPT(Mu:D, Junction:D) candidate, both create significant spectest fallout.

[lizmat]

@niner @vrurg @ugexe @japhb @JJ @codesections ping :-)

[lizmat]

Related: rakudo/rakudo#4618

[raiph]

(This comment edited down to this line as I've decided it's noise. Click Edited beside my name if you want to see what it was.)

[JJ]

2. What do we recommend users as an alternative??

hyperoperators and/or reduce will probably work nicely

[vrurg]

I'm not pretending to fully understand all the problems with junctions and ACCEPTS. My preferred way of using junctions is to have them on RHS as it mostly makes things more readable. This is especially true since the moment I realized that smartmatching is not commutative.

Yet, at least one place I see things done wrong and some of us trying to make conclusions based on that. @raiph refers to rakudo/rakudo#2676 and otherwise related issues. So, I started there. First, I wanted to see things in action. So, I done this:

class C {
    method ACCEPTS(\topic) {
        say "ACCEPTS(", topic, ")";
        (1..9).ACCEPTS(topic);
    }
}
say (0,3).one ~~ C.new;
say (0,3).one ~~ 1..9;

The class wrapper does what is expected despite falling back to the same Range.ACCEPTS. So, I pulled up the source:

    multi method ACCEPTS(Range:D: Mu \topic) {
        (topic cmp $!min) > -(!$!excludes-min)
          and (topic cmp $!max) < +(!$!excludes-max)
    }

Of course we get wrong outcome. With rakudo/rakudo#4618 this should complain, as to my understanding. But at the moment it's not the autothreading which breaks the smartmatch, but rather lack of it.

I was somewhat curious as to what happens if I enforce threading by introducing multi sub infix:<~~>(Junction:D \topic, Mu \matcher) candidate. It doesn't work out of the box due to the compiler stepping in first and optimizing the case. But cutting the compiler off by wrapping the smartmatch into a sub happens to also produce correct behaviour with the Range. So, here is the "fixed" version of smartmatch:

multi sub infix:<~~>(Junction:D \topic, Mu \matcher) {
    (topic.THREAD: { matcher.ACCEPTS: $_ }).Bool
}

And then the test code:

sub match(Mu \topic, Mu \matcher) {
    topic ~~ matcher
}
say so match((0,3).one, 1..9); # True

Tests with any, all, and none produce expected results too.

rakudo/rakudo#2814

I've got @lizmat golf:

say <a>.classify: * eq "a"|"b";  # {False => [a], True => [a]}

What happens here is rather understandable and expected: we autothread over classify. In the current paradigm I see nothing wrong with it, event though it's a WAT case. Then it came to my mind to test a thing I never tried before:

say ("a"|"b" => "c").raku; # any("a", "b") => "c"

So, why can't this be the answer? I mean, wouldn't it look reasonable to get { any(True, False) => ["a"] }?

At this point I must admit the experiments took too much of my time and I can't look into other problematic points. But I rather convinced myself that what is needed is thorough clarification of signatures and use cases. Perhaps and likely there will be individual cases where use of junctions just doesn't make sense. But so far I consider the deprecation as overkill.

BTW, talking about things not making sense:

say so 1 cmp 0; # True
say so 1 cmp 1; # False
say so 1 cmp 2; # True

Really??? ;) Either Order must not boolify whatsoever, or enum values must boolify against the rules for numerics.

[raiph]

@vrurg

Thank you for doing some initial analysis of the issues I listed.

say (0,3).one ~~ C.new;
say (0,3).one ~~ 1..9;

at the moment it's not the autothreading which breaks the smartmatch, but rather lack of it

But, aiui, per (@)Larry (including jnthn), it needs to not autothread. So this would remain broken, which would be "fine".

say <a>.classify: * eq "a"|"b";  # {False => [a], True => [a]}

so far I consider the deprecation as overkill.

By "the deprecation" do you mean the use of junctions with classify as discussed in 2814 or the deprecation that is implicit in what (@)Larry (including jnthn) say needs to occur for things to work sanely and properly performantly (and which I think liz and myself and presumably at least some others already tentatively anticipate is going to happen at 6.e)?