One nice thing that putting it in core could do that I (with a module) couldn't is allow it to have two forms, like map. If I prototyped it as (\&@), it wouldn't work with the old syntax. If I don't prototype it, I have to spell out sub.
Even if that weren't an issue, a good chunk of the benefit is that you don't have to use any modules. Admittedly, having a built-in vs. a module is a small benefit, but it's a small change with no apparent downside, except that you apparently find it confusing as heck.
Obviously, it would require an adjustment to the way one looks at join, but it's not a complete transformation, it's merely an extension. Currently, a join operation is a special case of reduce. My proposal is that it be given the ability to operate in a more general way. This introduces no keywords and doesn't affect backward compatibility (except for the very unlikely case that someone wanted to construct strings that look like aCODE(0x225e84)b or aHASH(0x2250f8)b (in which case they'd need to explicitly stringify).
Caution: Contents may have been coded under pressure.
| [reply]
[d/l]
[select] |