Apocalypse 3

rob_99 writes: "The third installment of the Apocalypse is out!" You may have missed the first or second Apocalypses. This one is roughly "all about operators".

No, result should depend on types of operands

[SMN]

'a'+'b' = 'c'?
'a'+'b' = "ab"?

No, the results of this should rely on the type of the operands, as it does with numerical values in C and C++ and most C++ classes. Keep in mind that single quotes denote a character (really an 8-bit ASCII value), and double quotes indicate a string (usually zero-terminated):

'a' + 'b' = 'Ã'
(char and char results in another char by adding their ASCII values)

"a" + 'b' = "ab"
(string and char results in a string by concatenation)

'a' + "b" = "ab"
(char and string -- order does not matter, so see string and char above)

"a" + "b" = "ab"
(string and string results in a string by concatenation)

To summarize, if a string is involved, then the char(s) is (are) promoted up to string(s) and the result depends on concatenation. If all operands are chars, then no promotion occurs and they are added by ASCII value.

This is similar to the numerical addition rules of C, C++, and a number of similar languages. One simple example: If an int and a float are added, the int is promoted to be a float and the result is a float. If an int and an int are added, the result is an int and must by cast (either explicitly or implicitly) in order to be a float value.

I'm not too familiar with Perl, but this seems to be the most sensible behavior. If I'm missing something and there's a valid reason not to use an addition sign for concatenation, please reply and let me know.

Re:Sweet! Hyperoperators!

[OddHackGEA]

> $a = $b.$c;
> print "Hello: ".$you."\n";
>
> becomes
>
> $a = $b _ $c;
> print "Hello: " _ $you _ "\n";

Or just

$a = "$b$c";
print "Hello: $you\n";

like you can do right now.

I can't tell yet whether "$a:b" will change, but presumably the Perl5 clarification "${a}:b" would still work.

Re:Not a good title

[Matchstick]

See the definition:

Apocalypse \A*poc"a*lypse\, n. [L. apocalypsis, Gr. ?, fr. ? to uncover, to disclose; ? from + ? to cover, conceal: cf. F. apocalypse.] 1. The revelation delivered to St. John, in the isle of Patmos, near the close of the first century, forming the last book of the New Testament. 2. Anything viewed as a revelation; a disclosure.

Or read the first paragraph of the first apocalypse [perl.com]:

People get scared when they hear the word Apocalypse, but here I mean it in the good sense: a Revealing. An Apocalypse is supposed to reveal good news to good people. (And if it also happens to reveal bad news to bad people, so be it. Just don't be bad.)

Re:More eclectic, less practical...

[Fixer]

Okay. All languages that are Turing complete are equivalent, as you well know. So why do we need more than one language?

Functional languages and parentheses

[V.P.]

Actually, not all functional languages use parentheses; that's just Lisp & friends. In modern functional languages like Haskell [haskell.org], you end up using fewer parentheses (and other punctuation) than in C, Python, or Perl.

For example, Haskell parses f 0 + f 1 as: f(0) + f(1) (In a less obvious way, it also parses f g x as f(g, x), but that's another story...)

Re:More eclectic, less practical...

[tstock]

Your FOREACH and FOR example is without merit.

ripped from perlsyn (man perlsyn):

The `foreach' keyword is actually a synonym for the `for' keyword, so you can use `foreach' for readability or `for' for brevity.

I do agree on your point though, you just choose a bad example and topic, since 'Efficiency' for perl *normally* means coding better and faster, not running faster.

Re:No, result should depend on types of operands

[James Lanfear]

No, the results of this should rely on the type of the operands, as it does with numerical values in C and C++ and most C++ classes.

They do, but the rather essential point that your missing is that in Perl both 1 and "1" are scalar -- they have the same type (in an obviously broader sense of the word). "1" + "1" produces "2" (or 2), as does 1 + "1", "1" + 1, and 1 + 1; and, as you might expect, "1" . "1" and 1 . 1 (note the whitespace) produces "11". Thus the need for distinct syntax, which is already present in the equality operators, where you have == vs eq, > vs gt, etc.

Keep in mind that single quotes denote a character (really an 8-bit ASCII value), and double quotes indicate a string (usually zero-terminated)

As has already been stated, single and double quoting controls variable interpolation in Perl; there are no character constants as such. And since we're playing lanaguage lawyer, (non-wide-)character constants in C are actually int's, and are not required to be ASCII (which only uses 7 bits, anyway), and strings are by definition null-terminated.

I'm not too familiar with Perl

Which begs the question of why you posted in the first place.

Re:Concatenating strings

[motb]

'He stresses the importance of good huffman coding, then goes on to change the string concatenation operator "." to a three character sequence " _ "'

Actually, I'd be surprised to see that stick around once Unicode support is rock-solid on the popular platforms. Larry mentions using non-ASCII operators, and I'm almost sure string concatenation will use one of these.

For my part, though, I actually like spaces around most binary operators, and wouldn't be upset to see it enforced in the language. That way, people would write unreadable code in my style of unreadable coding. ;)

I'm looking forward to non-ASCII operators. I understand they were much loved on the Lisp machines, and much hated in APL. Different ways of handling things in the two languages, though, so it might be a contextual thing. It will be interesting to see how they are received after twenty years or so of disuse.