One obvious reason for reaching out to unicode characters is the
restricted number of non-alphanumeric characters in ASCII. But why do
infix operators have to be non-alphanumeric?
They don't - but they do have to "look like operators". Thanks to the
multiplication symbol, lowercase 'x' looks like an operator to many
people. Most alphanumerics don't.
The rule is that, since the infix operator space and the sub-without-parens space intermix, and the subs namespace is very user-extensible, we shouldn't create places where they're likely to intersect and surprise the user. This is primarily in non-aphenumerics.
Also, users expect operators to look more or less like the ones they know, which are funny symbols. x and xx is a bit of a corner case -- I think it's a bit far, perhaps, but OTOH, x does look like the operator people use for this, and if we already have x (and we do), xx is reasonable.
I think the ¥(yen) suggestion is great, especially since it does indeed look like a zipper. Still, I would very much like an ASCII infix alternative for zip().
I propose z as the ASCII alternative for the infix zip operator (either broken bar or yen). With some imagination, it is a good candidate for representing interleaving. Besides that, zip() starts with a z so it is easy to remember even if you don't think it looks like something that zips.
I think if we go with ¥ for the Unicode operator, the logical choice for an ASCII equivalent would be Y. You could read it as Spanish "and", if you like. :)
I like ¥ for the zip operator. It looks like a zipper, it's a funny symbol, it's latin-1, and it's typeable on my keyboard (altgr-shift-z, German xfree86 keyboard).
Japanese users used to having problems with ¥ vs \ may be confused by that, but I think it's livable.
I don't think it needs an ASCII equivlient, though -- it isn't /that/ useful, and it already has an ASCII equivalent: the zip() function. Let Y be used by user subs, or as a user operator; it's too likely to confuse.
