[klibertp]

You're making a mistake if you're thinking like that. Applying an operation that generally works on single values over a list of values automatically is an incredibly powerful technique. If you have ever used Numpy, you will appreciate not needing it in many cases where Raku's built-ins suffice.

[JadeNB]

> You're making a mistake if you're thinking like that. Applying an operation that generally works on single values over a list of values automatically is an incredibly powerful technique.

Indeed, the defining technique of array programming!

[ekidd]

My fundamental objection here it that it is recursive. The non-recursive hyperoperators all have nice clean mathematical definitions. The recursive ones are just weird and ad hoc, at least from the perpective of the underlying mathematical structures.

[derefr]

And if you try to avoid the ad-hoc-ness by formalizing each useful weird behavior as its own documented type with its own documented semantics for application, then you've just reinvented monads. (Which is not to say you shouldn't; IMHO stdlib support for monad types in a dynamic scripting language is long overdue.)

[PittleyDunkin]

The operation itself is trivially useful but the operator soup makes me want to run screaming.

[tail_exchange]

You're right. It makes way more sense when you compare it to Numpy.

[IshKebab]

That's not really the issue here. The problem is they've elevated this super weird recursive looping operation to the level of a built-in operator.

Built-in operators should be reserved for tasks that are extremely common and have obvious behaviours.

This would be more suitable as a function, like

    applyBroadcast([1, [2, 3], 4, 5], [10, 20], +, recursive=true, loop=true)

There are so many subtle behaviours in `<<+>>` that you really want to spell out. Did you notice that it was [22, 23] not [22, 13] for example?