Re: z ip
Piers Cawley skribis 2004-03-29 16:33 (+0100): > You'll really confuse the deep functional programmers if you do that, > for whom the term 'Y operator' means something very different Probably, but is that a good reason to not use it? Many Perl 6 things will already really confuse Perl 5 programmers; why should programmers of languages that aren't even Perl be treated differently? Juerd
Re: z ip
"Mark J. Reed" <[EMAIL PROTECTED]> writes: >> 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. :) You'll really confuse the deep functional programmers if you do that, for whom the term 'Y operator' means something very different -- Beware the Perl 6 early morning joggers -- Allison Randal
Re: z ip
Mark J. Reed wrote: 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.
Re: z ip
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
Re: z ip
> I have quite a few fonts, the only one I can find where | is a broken > bar is "Terminal", a font for DOS programs that uses the cp437 > charset, which is incompatable with latin1 (? and ? are AE and AF > instead of AB and BB) and it dosen't even havI have quite a few fonts, > the only one I can find where | is a broken bar is "Terminal", a font > for DOS programs that uses the cp437 charset, which is incompatable > with latin1 (? and ? are AE and AF instead of AB and BB) and it o, it > dosen't seem like a problem. The console font my (modern) laptop boots also has | as a broken bar, but it is iso-8859-1, not cp437. Also, the following fonts in my Debian GNU/Linux /usr/share/consolefonts have a broken |: Cyr_a8x14.psf.gz Cyr_a8x16.psf.gz Cyr_a8x8.psf.gz alt-8x16.psf.gz alt-8x8.psf.gz altb-8x16.psf.gz altc-8x16.psf.gz aply16.psf.gz arm8.psf.gz default8x16.psf.gz default8x9.psf.gz gr.f14.psf.gz gr.f16.psf.gz gr737-9x14-2.psf.gz gr737-9x14.psf.gz gr737-9x16-medieval.psf.gz gr737-9x16.psf.gz gr8x14.psf.gz gr8x16.psf.gz gr8x6.psf.gz gr8x7.psf.gz gr8x8.psf.gz greek.psf.gz iso01a-8x8.psf.gz iso02.f14.psf.gz iso02.f16.psf.gz iso02g.psf.gz iso03.f14.psf.gz iso03.f16.psf.gz iso03g.psf.gz iso04.f14.psf.gz iso04.f16.psf.gz iso08.f08.psf.gz iso10.f14.psf.gz iso10.f16.psf.gz koi8-8x14.psf.gz koi8-8x16.psf.gz koi8-8x8.psf.gz koi8b-8x16.psf.gz koi8c-8x16.psf.gz koi8u_8x14.psf.gz koi8u_8x16.psf.gz koi8u_8x8.psf.gz lat0-sun16.psf.gz lat2-08.psf.gz lat2-10.psf.gz lat2-12.psf.gz lat2-14.psf.gz lat2-16.psf.gz lat2-sun16.psf.gz lat2u-08.psf.gz lat2u-10.psf.gz lat2u-12.psf.gz lat2u-14.psf.gz lat2u-16.psf.gz lat7-14.psf.gz ruscii_8x14.psf.gz ruscii_8x16.psf.gz ruscii_8x8.psf.gz tcvn8x16.psf.gz viscii10-8x16.psf.gz This is 61 out of 184 fonts. Broken pipe for | is too common to use the unicode symbol for this to mean something else. Even if it weren't, it would still be too similar. Juerd
Re: z ip
--- Juerd <[EMAIL PROTECTED]> wrote: > Kara Perlistoj, > > the zip operator is a useful one. I like it a lot. But I've been writing > zip() all the time, even though I think an infix operator is nicer. (Not > for for though, because you also have commas in the pointy sub's > parameter list.) > > 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 have quite a few fonts, the only one I can find where | is a broken bar is "Terminal", a font for DOS programs that uses the cp437 charset, which is incompatable with latin1 (« and » are AE and AF instead of AB and BB) and it dosen't even have a ¦. So, it dosen't seem like a problem. __ Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. http://taxes.yahoo.com/filing.html
z ip
Kara Perlistoj, the zip operator is a useful one. I like it a lot. But I've been writing zip() all the time, even though I think an infix operator is nicer. (Not for for though, because you also have commas in the pointy sub's parameter list.) 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. 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? It has never been a problem for 'x', has it? And with Perl 6 we even get an infix xx operator. 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. Regards, Juerd
