Slashdot Mirror
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."
http://www.ozonehouse.com/mark/blog/code/PeriodicT able.pdf
I the only one who saw the adobe acrobat plugin for firefox on his knees loading this?
Courtesy of Google:
e %3Ahttp%3A%2F%2Fwww.ozonehouse.com%2Fmark%2Fblog%2 Fcode%2FPeriodicTable.pdf&btnG=Zoeken
http://www.google.nl/search?hl=nl&ie=UTF-8&q=cach
user@host$ diff
A mirror location for the PDF of the periodic table: http://condor.madoka.be/various/PeriodicTable.pdf
I'm also hosting the PDF directly, here:
PeriodicTable.pdf
user@host$ diff
Mirror mirror on the (Larry) Wall...
.Mac
Bandwidth courtesy of
_______
2B1ASK1
Here it is.
You can't judge a book by the way it wears its hair.
Why is "&&" different from "and"? Ditto for "||" and "or", etc.
It's always been that way, at least for perl 5 (I have no earlier perl knowledge)
and and or have much lower precedence than && and ||, the idea being that the latter should be used for logical expression ($a || $b), and the former for a sort of concise control structure (using short circuit evaluation), i.e.Since they have such low precedence, it's (practically?) guaranteed that you can safely use them for that, and they will be evaluated only after the entire first operand.
A Minesweeper clone that doesn't suck
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.
You obviously never studied mathematics, 3 and 2.999... are exactly the same.
Programming != what is theoretically true in math. All I got is these 32 or 64 or 80 bits and there isn't any mathemetician of any IQ that can make 2.9999... in IEEE floating point equal 3.0 exactly.
Vote in November. You won't regret it.
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.
Thank you for the kind comments.
I used Omnigraffle 3 (standard edition) running on Mac OS X (10.3).
- Mark