Periodic Table of the Operators

mAsterdam writes "At his code blog Mark Lentcner writes: "A while back, I saw Larry Wall give a short talk about the current design of Perl 6. At some point he put up a list of all the operators - well over a hundred of them! I had a sudden inspiration, but it took a few months to get around to drawing it..." You might want to take a look at this and think about which operators are yet to be discovered."

Comments

Oh my sweet Jesus...

[btlzu2]

This cannot mean good things for Perl. Look at all of those operators!!!! Correct me if I'm wrong, but isn't that pretty onerous to have a huge chart of possible operators for a language? I'd quite prefer simplifying over adding multiple combinations of ways to doing things. That code is gonna be NASTY.

All the more reason for me (IMO) to avoid Perl like the plague.

Re:Oh my sweet Jesus...

[BokLM]

If you don't want more than one way to do it, then Perl is not for you ...

Re:Oh my sweet Jesus...

[mcc]

come on.. different types of compare operators that work on regular variables (one for numbers, one for strings)? Can't the interpreter just say "Oh, one of these is a string, internally.

This duality is already a feature of Perl and it actually is a necessity. The reason is that string compare and numeric compare are different desired operations.

Let us say that perl used == for both string and numeric compare. Now let us say that someone wrote the following statement in a perl program: "3.0" == "3". Does this return true or not? If we perform a numeric compare, then yes. If we perform a string compare, then no. Now, you can point at my example and say that since 3 and 3.0 were both quoted here, clearly the programmer intended for 3 and 3.0 to be treated as strings. However, if rather than literals those had been variables-- maybe taken from user input-- that would have been no such indicators. The language has no way to tell what to do.

This really so much isn't about types as it is about the fact perl will autobox numbers in and out of strings for you. I'll give you Perl has many features that just make one's head hurt, but this isn't one of them.

Re:Oh my sweet Jesus...

[Jerf]

However, if rather than literals those had been variables-- maybe taken from user input-- that would have been no such indicators.

Here is where your argument falls down. Proof by construction: There are a large number of languages of every variety that still manage to have types for that input.

Your argument is more accurately described as:

"Perl actively tries to avoid giving types to strings and numbers, and as a result of this desire to not distinguish between the two, the onus is on the programmer to do so. That's how the language solves this problem that other languages solve through stronger typing."

At this point, one can then go on and debate whether or not this is a good thing, but don't pretend that Perl has no choice. It had all kinds of choice and deliberately chose this system, most likely for backwards programmer compatibility with awk and its other predecessors.

Perl isn't "autoboxing"; that's a technical term that means that you take simple C++ or Java style scalars and automatically wrap them in an object. Perl is dynamically "looking at" the object as either a number or a string, depending on context; thus, to the programmer, every string is also a number (albiet usually 0) and every number is also a string.

Re:Oh my sweet Jesus...

[imroy]

You're thinking about strongly typed languages e.g C, C++, Java, C#. In those language variables are only ever of one type. When copying from one type to another, or comparing different types, there are strict rules of "promotion" (i.e we always promote to higher-precision types).

Perl is a weakly typed language. There's three main variable types: scalar, list (array), and hash (associative array). Scalars can be both numerical and text strings at the same time. This is the reason that Perl has different equality tests for numbers and strings. The run-time has to to be explicitly told which comparison to use. For an example of how not to handle this situation, just look at the way PHP does it. When a language is weakly typed, the interpreter/run-time loses information about how certain things are to be done with variables. That information loss must be made up somwhere. In this case, it's the operators.

Re:Oh my sweet Jesus...

[mcc]

"Perl actively tries to avoid giving types to strings and numbers, and as a result of this desire to not distinguish between the two, the onus is on the programmer to do so. That's how the language solves this problem that other languages solve through stronger typing."

Stronger typing does not automatically solve this particular issue. Look at, for example, C. It uses == for numeric compare and strcmp() for string compare. Strong typing does not help here; ==, as in perl, means only one thing, and that one thing is "compare two numbers".

Now, you *can* in C++ overload the == operator on a string class you create-- or in Java the equals() method-- to do custom comparisons on specific types. However this then brings up the question of what happens if for some reason you want to do a numeric compare between two string objects. You have to somehow do a conversion to a different object type. Perhaps this is a bit clumsy. So yes, certain applications of strong typing lead to a potential way to trick the language into allowing you to perform the two different operations of string and numeric comparison with only a single operator. However you have unfortunately in doing so introduced ambiguity into your definition of equality. This does not necessarily seem like a win to me.

It is worth noting that Perl 6 offers the opportunity to strongly type your variables, and this includes numeric types. However it still uses the separate == and eq operators for numeric and string compare even when this strong typing is effect, simply as a design choice. I think this is a good one: there are already far too many situations where an operator or function in Perl behaves in different ways depending on minor details of the context, we do not need another. Again, I assure you, you are better off going to find some other grounds on which to attack Perl. You will not have to look long.

Incidentally, I used the term "autoboxing" in the sense that Perl is automatically converting data entities from string to numeric types (yes, the variables may not be "typed", but the data certainly can be said to be). I was not aware the term "autobox" referred only to conversions between object and non-object types. Oops.

Undiscovered: the /. operator

[thomasdelbert]

The /. operator is the one that causes your system to grind to a halt.

- Thomas;

Re:Cache?

[technix4beos]

Courtesy of Google:

http://www.google.nl/search?hl=nl&ie=UTF-8&q=cache %3Ahttp%3A%2F%2Fwww.ozonehouse.com%2Fmark%2Fblog%2 Fcode%2FPeriodicTable.pdf&btnG=Zoeken

PDF mirror

[Cond0r]

A mirror location for the PDF of the periodic table: http://condor.madoka.be/various/PeriodicTable.pdf

I looked all over.

[Phidoux]

Where is the WTF operator?

Some of these have a halflife of a few nanoseconds

[JCCyC]

Code written with them becomes illegible after that.

Perl 6

[Anonymous Coward]

Perl 6 is going to be the best thing that ever happened to Python.

Relevant excerpt from the INTERCAL language manual

[mcc]

TONSIL A (1)

The Official INTERCAL Character Set

Tabulated on page XX are all the characters used in INTERCAL, excepting
letters and digits, along with their names and interpretations. Also
included are several characters not used in INTERCAL, which are presented
for completeness and to allow for future expansion.

Character Name Use (if any)

. spot identify 16-bit variable
: two-spot identify 32-bit variable
, tail identify 16-bit array
; hybrid identify 32-bit array
# mesh identify constant
= half-mesh
' spark grouper
` backspark
! wow equivalent to spark-spot
? what unary exlusive OR (ASCII)
" rabbit-ears grouper
". rabbit equivalent to ears-spot
| spike
% double-oh-seven percentage qualifier
- worm used with angles
< angle used with worms
> right angle
( wax precedes line label
) wane follows line label
[ U turn
] U turn back
{ embrace
} bracelet
* splat flags invalid statements
& ampersand[5] unary logical AND
V V unary logical OR
(or book)
V- bookworm unary exclusive OR
(or universal qualifier)
$ big money unary exclusive OR (ASCII)
c| change binary mingle
~ sqiggle binary select
_ flat worm
overline indicates "times 1000"
+ intersection separates list items
/ slat
\ backslat
@ whirlpool
-' hookworm
^ shark
(or simply sharkfin)
#|[] blotch

Table 2 (top view). INTERCAL character set.

(1) Since all other reference manuals have Appendices, it was decided that
the INTERCAL manual should contain some other type of removable organ.

(2) This footnote intentionally unreferenced.

Re:the pdf file

[maswan]

I put up a mirror of that file here: PeriodicTable.pdf

The current server seems a bit slow to respond, so..

/Mattias Wadenstein

Awful! XD

[Apage43]

Take a look at this, then take a look at a real periodic table. Yup, that's right, a list of the operators of perl are more complicated than a list of all the atoms that make up everything around you. Mirror (Bittorrent so I wont get myself /. ed) http://www.raiden.se/download/1541/PeriodicTable.p df.torrent

Can't seem to find it...

[mcc]

We may have to wait for Perl 7 for that one. However, if you look under "Quasi Variables/Templars", you will find there is a "yadda, yadda, yadda" operator.

Operators considered optional.

[mcc]

One of the underlying philosophies about perl is to give the user as many options for doing things as is concievably possible. However, there's certainly no reason you have to take these options or, generally, to know those options are there. I repeat: you do not have to know these operators to use perl 6. There is almost nothing on this entire graph for which you could not get the same functionality in a more clean and readable manner by just doing it a different way.

There is no doubt that a cleaner and more consistent language would arise from putting all the language functionality into clear and well-organized paths that everyone would use and recognize in exactly the same way. However the thing is, that is not what many people want. And I would posit that the popularity of perl proves that that is not what people want. While this chart may horrify many programmers, the simple fact is that one of the main reasons for the popularity of perl is the freedom offered by all of its shortcuts and bizarre little unnecessary operatorss. Someone programming in, say, Java, will find themselves often having to stop, scratch their heads, and try to remember or look up the method or class in the standard library used to do some trivial thing, or write a trivial function to do it themselves. While the perl programmer just scribbles out &$g =~ /(.)/g or the first thing that comes to their mind and moves on.

Perl 6's one big problem, from my perspective, is that the language is *so* big that it's unlikely or impossible any one person will be familiar with all of its features. However one of these features-- which is either horrible or very attractive depending on how you look at it-- is that it offers you the opportunity to redefine the syntax. My personal theory is that many organizations which decide to adopt perl 6 internally will use this to just cut out large swaths of the language, cutting perl 6 down to something more streamlined and manageable. That is, in order to ensure everyone can read each other's code, they will be able to just set certain coding standards-- for example, "don't use hyper operators" or "don't alter the perl grammar"-- and then enforce this by requiring everyone to include a lib that simply removes these features from the language. Do something like this, and you're left with a language which is readable yet still perfectly functional and still more attractive in many ways than many other languages.

This doesn't help though with the reason this is a big problem, though: code reuse. Perl 6 offers so many options that code written by another person or another organization, when it falls in your hands may sometimes appear to have been written in a different language than the one you are used to. And if people have been taking advantage of the syntax-redefinition features, it will literally be in a different language. However, I suspect this will not be an intractable problem for one reason. Perl 6 offers a very robust object system; it is likely that most of the code reuse in perl 6 will be done through modularity and incorporation of objects, rather than simple cut and paste code reuse. This is in fact generally the way that things work in perl 5; people just modularize everything, and learn not to poke too closely at the internals of any class they're given to work with, looking only at the perldocs. Weirdly, despite the illegible code (or perhaps because of it), the perl culture, or at least the perl module community, seems to have developed a tendency to write very exhaustive documentation. Anyhow, we shall see what happens.

One last thing. This chart is not as bad as it seems. Most of the size of this chart stems from the explosion of "operators" caused by the addition into perl 6 of APL-style "adverbial operators". (I believe the user may define their own adverbs, but I am not sure.) This means that many of the operators on this list are actually compound operators-- for example, the "add the contents of two lists" oper

Re:Brace yourself...

[Dr. Zowie]

Why is "?:" spelled "??::" ?
Because "?:" is a logical (short-circuit; control flow) operator. The newer spelling makes it look more like "&&" and "||".
Why is "&&" different from "and"? Ditto for "||" and "or", etc.
Precedence, my friend, precedence. That already exists in perl 5. The spelled-out operators have much lower precedence than && and friends -- so you can say
if( $a = shift and $a=~m/foo/ ) { ... }
conveniently. ($a gets the shifted value, not the boolean AND of the shifted value and the match).
"." is now "~"?
Well, three good ones out of four ain't bad... IMHO this is dumb. The reason is that "->" is now "." (saving some keystrokes, I suppose) -- but I'd rather leave both operators as-is.
Charwise operators?
Yes, excellent stuff! I believe that this is actually driven by the PDL application -- there, you have large arrays (e.g. several million entries) and want to do vast vectorized operations on them. Currently PDL uses the perl 5 bitwise operators for vectorized ops -- but that's not a perfect fit, since sometimes you do actually want bitwise operations.

This is a beautiful diagram

[dozer]

Excellent antialiasing, excellent fonts with good kerning, great drop shadows, lots of repititive work assembled pretty much flawlessly... This chart gets an A+ for style (which is pretty rare in the non-Mac Unix world).

Does anybody know the tool Mark Lentcner used to make it? Illustrator? Could I be so bold as to hope that Sodipodi or Inkscape are now capable of something like this?

unfortunately, you still have to READ others' Perl

[mkcmkc]

you do not have to know these operators to use perl 6

Unfortunately, you still have know these operators in order to READ Perl code written by other programmers.

Perl 5 is already conceptually too large to use. Perl 6 just takes things completely over the top.

Mike