Juerd: your message arrived in my inbox as an attachment due to a mail server along the way not recognizing the "charset" value. It should be "utf-8" with the hyphen, not "utf8". Also for that reason all the non-ASCII characters (like the Yen symbol) came through as '?' here.
> Kara Perlistoj, And that should be "Karaj" to agree with the modified noun. :) > However, the broken bar is in my opinion a bad choice. As some have > pointed out, because the similarity with |. Historically, 1, l, I and | > have always aided in obfuscation. Adding a(nother) broken bar to it > would be a mistake. I agree here. Whether | has a break in your font or not, we don't need yet another tall, skinny character to add to the confusion. (Although "I" doesn't belong on the list. Anyone using a sans-serif font for programming purposes completely deserves any confusion that results. :)) > 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. > 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. :) -Mark
