Этот код работает так, как ожидалось:
sub infix:<mean>(*@a) {
@a.sum / @a.elems
}
sub Mean (*@a) {
@a.sum / @a.elems
}
say EVAL 'Mean 2, 6, 4'; # Output: 4
say EVAL '2 mean 6 mean 4'; # Output: 4
Он работает, как и ожидалось, когда строка 7 находится в своей области:
{say EVAL 'Mean 2, 6, 4';} # Output: 4
Но когда строка 8 находится в своей области:
{say EVAL '2 mean 6 mean 4';}
===SORRY!=== Error while compiling .../EVAL_1
Two terms in a row
at .../EVAL_1:1
------> 2⏏ mean 6 mean 4
expecting any of:
infix
infix stopper
statement end
statement modifier
statement modifier loop
Почему к двум сабвуферам относятся по-разному?





Это известная проблема, также затрагивающая REPL.
Проблема в том, что выполнение строки EVAL «увидит» окружающую область со всеми ее дополнениями, поэтому:
say EVAL 'infix:<mean>(infix:<mean>(2, 6), 4)';
даст 4, потому что известен сабвуфер &infix:<mean>(*@a).
Но изменения грамматики, позволяющие ему работать как инфикс, в настоящее время не видны внутри EVAL. И именно поэтому вы видите ошибку времени компиляции.
Я очень надеюсь, что мы сможем исправить это с помощью новой грамматики Raku, основанной на RakuAST.
К вашему сведению код в Q в настоящее время работает в glot.io (который сообщает, что использует Rakudo 2202.02).
Интригующий! Думаю, кому-то нужно сделать биссектрису тогда.
Когда я запускаю код, который вы показываете, в Rakudo 2022.02, все работает. Мои две гипотезы: 1: вы используете REPL, который содержит ошибки (см. Почему в Raku REPL не сохраняются новые определения операторов?) или 2: какая-то связанная или другая ошибка есть в последних Rakudos (которые В настоящее время я думаю маловероятно, но все же). У меня сейчас нет времени на дальнейшее расследование.