FW: Periodic Table of the Operators
Joe Gottman
> -----Original Message-----
> From: Mark Lentczner [mailto:ma...@glyphic.com]
> Sent: Friday, May 28, 2004 7:18 PM
> To: perl6-l...@perl.org
> Subject: Re: Periodic Table of the Operators
>
> Not to beat a dead horse, but....
>
> I've updated the Periodic table with almost all the changes that people
> here sent me, as well as reading a few more threads and references.
> This will be the last update for some time
The zip operator is now the Yen sign (¥).
Joe Gottman
Gabriel Ebner
Joe Gottman wrote:
> The zip operator is now the Yen sign (¥).
How are those without a US keyboard supposed to type this?
Gabriel.
--
Gabriel Ebner - reverse "ta.renbeleirbag@eg"
Dave Whipp
Japanese, you probably won't have a problem ;-).
But for the rest of us, use Vi and <ctrl-K>Ye (or <space>zip<space>).
Dave.
"Gabriel Ebner" <g...@gabrielebner.at> wrote in message
news:3904041.z...@schnecke2.gabrielebner.at...
Smylers
> Joe Gottman wrote:
>
> > The zip operator is now the Yen sign (･).
>
> How are those without a US keyboard supposed to type this?
Probably the same way as those with US keyboards do -- US keyboards
don't have a yen symbol on them either.
In 'Vim' I got lucky in guessing it first time as Ctrl+K Y e. On
Windows you can probably press Alt Gr then type in some number. Or
pick it from the character map utility. Or keep Joe's mail handy so
that you can copy and paste it whenever you need it.
Or spell it out as zip and not use the operator form ...
Smylers
Rod Adams
>Gabriel Ebner writes:
>
>
>
>>Joe Gottman wrote:
>>
>>
>>
>>> The zip operator is now the Yen sign (･).
>>>
>>>
>>How are those without a US keyboard supposed to type this?
>>
>>
>On Windows you can probably press Alt Gr then type in some number.
>
>
Close. AltGr-Minus. If you're using the US-International layout that
ships w/ Windows.
-- Rod
Mark J. Reed
> >>How are those without a US keyboard supposed to type this?
I assume you mean "with" a US keyboard? US keyboards don't have ¥.
You can use " zip " if you want ASCII. Otherwise, it depends. But Yen is
Unicode codepoint U+00A5 = 165 decimal, so you can type it in Windows as ALT +
numpad 0165 even without any international keyboard layout. If you
use vim, then you can use control-V (control-Q on Windows) 1 6 5
(or u 0 0 a 5), or the Ye digraph (control-K Y e, or, if you have the digraph
option set, Y<backspace>e).
-Mark
Aaron Sherman
> Hello,
>
> Joe Gottman wrote:
> > The zip operator is now the Yen sign (¥).
>
> How are those without a US keyboard supposed to type this?
Well, first off my US keyboard doesn't contain it. Second, you're not
supposed to. ¥ is a shorthand for "zip", and if you don't want to use
the funky one-character operator, just use the afunked three-character
one.
--
Aaron Sherman <a...@ajs.com>
Senior Systems Engineer and Toolsmith
"It's the sound of a satellite saying, 'get me down!'" -Shriekback
Gabriel Ebner
Mark J. Reed wrote:
> I assume you mean "with" a US keyboard? US keyboards don't have ¥.
Oops, must have mistakenly picked an US-International chart, sorry.
Gabriel Ebner
Aaron Sherman wrote:
> Well, first off my US keyboard doesn't contain it.
Sorry, mistakenly picked an US-International chart.
> Second, you're not supposed to.
So why has it been chosen then?
> ¥ is a shorthand for "zip",
Good to know.
> and if you don't want to use the funky one-character operator,
Would I complain if didn't want to?
> just use the afunked three-character one.
Or just use vim as many (helpful) posts noted.
Paul Seamons
C-x 8 Y
C-x 8 <
C-x 8 >
Paul
Mark J. Reed
On 2004-06-01 at 14:10:08, Paul Seamons wrote:
> Or for the few Perl emacs people out there:
>
> C-x 8 Y
> C-x 8 <
> C-x 8 >
I suspect there are more than a "few". I don't think there's anything
constitutional about folks who like Emacs that prevents them from liking
Perl or vice-versa. Even though (e)lisp is about as orthogonal as you can get
and therefore something of a philosophical opposite to Perl. :)
Since you've added « and » to the list above, I'll add them as well:
Codepoint Decimal Vim Digraph
« U+00AB 171 <<
» U+00B1 177 >>
Details again: you can always enter chars into Windows by holding down
the ALT key and typing 0 plus the decimal code point on the numeric
keypad, or into Vim by hitting control-V (control-Q in vim on Windows,
since control-V is Paste) followed by either the decimal code point (no
leading 0) or the letter u plus the hexadecimal code point.
Vim digraphs are entered via control-K plus the two characters, or
by setting the 'digraph' option and then typing the two characters
separated by a backspace.
-Mark
David Cantrell
> Since you've added ? and ? to the list above, I'll add them as well:
What's so hard to type about the question mark? And what's so
significant that you added it twice?
OK, so I know that you really meant to type <some bizarre character> and
<some other bizarre character>.
This is what is so wrong about allowing unicode operators - yes, I don't
need to write them, but if some other programmer writes one I have to be
able to read it. And I can't.
--
David Cantrell | Reprobate | http://www.cantrell.org.uk/david
When a man is tired of London, he is tired of life
-- Samuel Johnson
Mark J. Reed
On 2004-06-07 at 21:33:03, David Cantrell wrote:
> This is what is so wrong about allowing unicode operators - yes, I don't
> need to write them, but if some other programmer writes one I have to be
> able to read it. And I can't.
Well, for one thing, just because your email program doesn't let you display
them, that doesn't mean you can't see them in your text editor. If I
sent you a Perl program as an attachment I'm sure the "bizarre"
characters would come through fine.
And for another thing, what bizarre email system are you using that in
2004 can't even handle Latin-1? It's not like they were something from
way out in Unicodespace, nor was the message UTF8-encoded; just plain
old, garden variety, 8-bpc ISO-8859-1. They were, incidentally,
the guillemets; « = left-pointing (<<) and » = right-pointing (>>).
-Mark
David Cantrell
> On 2004-06-07 at 21:33:03, David Cantrell wrote:
>>This is what is so wrong about allowing unicode operators - yes, I don't
>>need to write them, but if some other programmer writes one I have to be
>>able to read it. And I can't.
> Well, for one thing, just because your email program doesn't let you display
> them, that doesn't mean you can't see them in your text editor. If I
> sent you a Perl program as an attachment I'm sure the "bizarre"
> characters would come through fine.
The data in the file would, of course, be preserved, but that doesn't
mean I could read it. Like when I was writing my earlier mail.
> And for another thing, what bizarre email system are you using that in
> 2004 can't even handle Latin-1?
My console can be any of several platforms - in the last couple of weeks
it has been a Linux box, a Windows PC, a Mac, a Sun workstation, and a
real vt320 attached to a Sun. My mail sits on a hosted Linux box. To
read it, I sometimes ssh in to the machine and read it using mutt in
screen. At other times I read it using Mozilla Thunderbird over IMAP.
In Thunderbird, the odd characters show up. But when I'm using a
terminal session, I have found that the only practical way of getting
consistent behaviour wherever I am is to use TERM=vt100. Windows is, of
course, the main culprit in forcing me to vt100 emulation.
--
David Cantrell | Failed to find witty sig
Tim Bunce
>
> My console can be any of several platforms - in the last couple of weeks
> it has been a Linux box, a Windows PC, a Mac, a Sun workstation, and a
> real vt320 attached to a Sun. My mail sits on a hosted Linux box. To
> read it, I sometimes ssh in to the machine and read it using mutt in
> screen. At other times I read it using Mozilla Thunderbird over IMAP.
> In Thunderbird, the odd characters show up. But when I'm using a
> terminal session, I have found that the only practical way of getting
> consistent behaviour wherever I am is to use TERM=vt100. Windows is, of
> course, the main culprit in forcing me to vt100 emulation.
I can recommend PuTTY for windows. Secure, small[1], fast, featureful
and free: http://www.chiark.greenend.org.uk/~sgtatham/putty/
I'm using it now to ssh from a windows laptop to read email using
mutt in screen.
Tim.
[1] So small it easily fits on a floppy. I keep a copy on my USB memory drive.
David Cantrell
I can get it working with a Windows client, or a Mac client, or a
$other_client, but I could never find any combination of voodoo that
would work with *all* clients, so that I can disconnect (while leaving
mutt running) then reconnect some random time later on some other
platform and have it Just Work and have odd characters show up correctly.
TERM=vt100 was the only way to get consistent results. Yes, I tried
putty. I also tried cygwin/xfree86/xterm/openssh, to no avail.
--
Lord Protector David Cantrell | http://www.cantrell.org.uk/david
Lefties are usually well-intentioned at least, and possess
a far greater command of grammar and spelling.
-- Noel, in soc.history.what-if
H.Merijn Brand
> On Tue, Jun 08, 2004 at 11:30:51AM +0100, Tim Bunce wrote:
> > On Mon, Jun 07, 2004 at 10:52:32PM +0100, David Cantrell wrote:
> > > But when I'm using a
> > > terminal session, I have found that the only practical way of getting
> > > consistent behaviour wherever I am is to use TERM=vt100. Windows is, of
> > > course, the main culprit in forcing me to vt100 emulation.
> > I can recommend PuTTY for windows. Secure, small[1], fast, featureful
> > and free: http://www.chiark.greenend.org.uk/~sgtatham/putty/
> > I'm using it now to ssh from a windows laptop to read email using
> > mutt in screen.
>
> I can get it working with a Windows client, or a Mac client, or a
> $other_client, but I could never find any combination of voodoo that
> would work with *all* clients, so that I can disconnect (while leaving
> mutt running) then reconnect some random time later on some other
> platform and have it Just Work and have odd characters show up correctly.
> TERM=vt100 was the only way to get consistent results. Yes, I tried
> putty. I also tried cygwin/xfree86/xterm/openssh, to no avail.
isn't that what 'screen' is for?
--8<--- man screen
SCREEN(1) SCREEN(1)
NAME
screen - screen manager with VT100/ANSI terminal emulation
SYNOPSIS
screen [ -options ] [ cmd [ args ] ]
screen -r [[pid.]tty[.host]]
screen -r sessionowner/[[pid.]tty[.host]]
DESCRIPTION
Screen is a full-screen window manager that multiplexes a
physical terminal between several processes (typically
interactive shells). Each virtual terminal provides the
functions of a DEC VT100 terminal and, in addition, sev-
eral control functions from the ISO 6429 (ECMA 48, ANSI
X3.64) and ISO 2022 standards (e.g. insert/delete line and
support for multiple character sets). There is a scroll-
back history buffer for each virtual terminal and a copy-
and-paste mechanism that allows moving text regions
between windows.
When screen is called, it creates a single window with a
shell in it (or the specified command) and then gets out
:
:
-->8---
--
H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using perl-5.6.1, 5.8.3, & 5.9.x, and 809 on HP-UX 10.20 & 11.00, 11i,
AIX 4.3, SuSE 9.0, and Win2k. http://www.cmve.net/~merijn/
http://archives.develooper.com/daily...@perl.org/ per...@perl.org
send smoke reports to: smokers...@perl.org, QA: http://qa.perl.org
Juerd
> I can recommend PuTTY for windows. Secure, small[1], fast, featureful
> and free: http://www.chiark.greenend.org.uk/~sgtatham/putty/
So small that even on modem lines, you can afford to download it each
time you start it: http://startputty.com/ - if you trust them.
Juerd
Pedro Larroy
What advantages have to use characters not in standard keyboards? Isn't
it a little scary?
Regards.
--
Pedro Larroy Tovar | Linux & Network consultant | piotr%member.fsf.org
Software patents are a threat to innovation in Europe please check:
http://www.eurolinux.org/
David Storrs
> What advantages have to use characters not in standard keyboards? Isn't
> it a little scary?
Well, what do you consider a 'standard' keyboard? The zip
operator/Yen sign probably appears on most keyboards in Japan, but on
very few in the US. My US keyboard gives me no convenient way to type
a 'u with umlaut' character, but I'm sure that my friend Roland, who
lives in Switzerland, has no such limitation.
Like it or not, Unicode is the way of the future. Life really and
truly will be easier once that becomes the default assumption;
keyboard makers will start putting thought into how to provide easy
access to normally-unused-in-this-locale characters, software will
have to make it easy to work with foreign character sets, your
terminal will not give you grief about displaying foreign characters,
etc.
But it's kind of a chicken-and-egg problem. If the characters are
never used, we don't need to worry about them--except when we do. So,
by making them more commonly used, we help bring about the day when we
don't need to worry about them.
And if you aren't ready to worry about them yet, I believe they all have
ASCII equivalents (e.g., >>, <<, and zip).
All the best,
--Dks
Jared Rhine
Pedro> What advantages have to use characters not in standard
Pedro> keyboards?
Flexibility.
Stylistic choice.
There is More Than One Way To Do It.
Power.
Expressiveness.
Everything that makes Perl good.
Pedro> Isn't it a little scary?
Yes, very. Great phrasing.
Scary enough that this same question will continue to be asked over
and over and over. You're not the only one afraid, believe me.
The "unicode operator" issue boils down to "even if you can't picture
using it yourself, there are lots of people who can find good uses for
it. And they should be allowed to do so if they wish."
It's extremely unlikely I personally will use Unicode operators in my
code. I haven't yet seen an example presented where using a Unicode
operator would save keystrokes, for instance. And it will likely be
easier for me to remember the "long" ASCII versions of any "short"
Unicode operators.
But it would be selfish and shortsighted to try to force that choice
onto everyone.
Yes, fragmentation may occur. You may occasionally get P6 code that
was written with a Unicode operator or two. You may have to pipe the
code through a standard "p6unicode2p6ascii" program to read and/or
edit it properly. But realistically, it's likely the community is
unlikely to use them widely and the defacto standard in public code
will be to stick with ASCII. If that doesn't happen, it will be a
good sign that there was actually great pent-up demand for Unicode
operators and people are glad they are around.
The only thing we have to fear (from the mere availability of Unicode
operators) is fear itself.
"One cannot mark the point without marking the path."
Rod Adams
>I haven't yet seen an example presented where using a Unicode
>operator would save keystrokes, for instance.
>
That depends entirely on how you plan to generate them. If you are
relying on a special command in your editor of choice, yes, the ASCII
equiv is fewer keystrokes. If, however, you remap your keyboard (easily
doable in X and Win32, I'd assume Macs can as well), then the common
Unicode characters are an AltGr away. Thus, « one shifted keystroke
(AltGr-[), << is two shifted keystrokes (Shift-, Shift-,).
-- Rod Adams
Jared Rhine
Jared> I haven't yet seen an example presented where using a Unicode
Jared> operator would save keystrokes, for instance.
Rod> That depends entirely on how you plan to generate them. If you
Rod> are relying on a special command in your editor of choice, yes,
Rod> the ASCII equiv is fewer keystrokes. If, however, you remap your
Rod> keyboard (easily doable in X and Win32, I'd assume Macs can as
Rod> well), then the common Unicode characters are an AltGr
Rod> away. Thus, « one shifted keystroke (AltGr-[), << is two shifted
Rod> keystrokes (Shift-, Shift-,).
Ok. A reasonable point that hasn't been made yet in this multi-month
discussion. It'll never actually "save" me characters, however; the
most I'll achieve is parity.
I'll be more likely to remap MyMod-> to the macro '>>' than that
similar-looking Unicodey character I don't know (or care) how to make
yet. And MyMod-Y to expand to 'zip', not <Unicode Yen>.
Presumably, the argument for Unicode operators needs to (and does) go
deeper than "saving keystrokes". TIMTOWTDI is the best argument I've
seen thus far, with this little keyboard remapping discussion as an
excellent example.