$x = ($d) ? do_one()
   : ($e) ? do_two()
   : ($f) ? do_three()
   :        do_default()
   ;
[download]

Further, I'd claim that "if/else" constructs are eaisier to maintain, because if you need to check for another case later it's easy to stick in "elsif" clauses, but with ternaries you end up with "cascading ternaries", which strike me as even harder to read.

Notably though, Conway in his "Best Practices" doesn't recommend against ternaries, instead he just recommends formatting cascading ternaries in columns to improve readability.

yes, readability at first is a problem with Mr. Ternary... i can't get wrong with that... but as often you use the ternary operator becomes handy. but wait my delima was this "\&". what was that execption for in the strict pragma?

yes, readability at first is a problem with Mr. Ternary... i can't get wrong with that... but as often you use the ternary operator becomes handy. but wait my delima was this "\&". what was that execption for in the strict pragma?

I think it is your dilemma, and yes: I had never seen it. Indeed, had you asked me, I would have guessed it was no valid syntax at all. And while I'm far from being a guru myself, I've seen quite a lot of code over the years, from gurus too. However reasoning on it a little, it's easy to see it simply amounts to taking a real reference after taking a symbolic dereference. The exception perldoc strict talks about is that that particular symbolic dereference, in that situation, doesn't issue an error, while it would in all the other situations:

C:\temp>perl -wMstrict -e "\&{'foo'}"
Useless use of reference constructor in void context at -e line 1.

C:\temp>perl -wMstrict -e "&{'foo'}"
Can't use string ("foo") as a subroutine ref while "strict refs" in us
+e at -e line 1.
[download]

Why you think you can use that instead of eval is completely out of my comprehension. The semantics is completely different.

well, overall its all about readability problems with Mr. Ternary...

to easily remember the structure of Mr. Ternary a multi-decision structuring as follows:

<expression> ?
   eval {
      <statement>;
      <statement>;
      <statement>;
      <expression> ?
          eval {
             <statement>;
             <statement>;
             <statement>;
          }
      :
          eval {
             <statement>;
             <statement>;
             <statement>;
          };
   }
:
   eval {
      <statement>;
      <statement>;
      <statement>;
      <expression> ?
          eval {
             <statement>;
             <statement>;
             <statement>;
          }
      :
          eval {
             <statement>;
             <statement>;
             <statement>;
          };
   };
[download]

NOTE: (eval or \& or do) well also work

literally, Mr. Ternary is more on simple symbols that gives you a more concentration on expressions and statements without being bothered with words like if, elsif, and else.

i don't think so that other languages could make Mr. Ternary more functional (making Mr. Ternary hold multiple-statements) than Perl could do. what do you think?

This looks quite orderly, since the only words you are using here are 'eval', 'statement' and 'expression'. If you fill that with 'real code', the picture will get different, and the tiny ':' will get hard to spot at a glance.

In contrast, 'if-elsif-else' statements stand out and are thus better readable on larger constructs.

As for \& {}, that's an abuse of the coderef constructor and it will clutter up your symbol table.

<expression> ? eval { <statement>; <statement>; <statement>; <expression> ? eval { <statement>; <statement>; <statement>; } : eval { <statement>; <statement>; <statement>; }; } : eval { <statement>; <statement>; <statement>; <expression> ? eval { <statement>; <statement>; <statement>; } : eval { <statement>; <statement>; <statement>; }; }; [download]

if (<expression>) { <statement>; <statement>; <statement>; if (<expression>) { <statement>; <statement>; <statement>; } else { <statement>; <statement>; <statement>; } } else { <statement>; <statement>; <statement>; if (<expression>) { <statement>; <statement>; <statement>; } else { <statement>; <statement>; <statement>; } } [download]

What do you do with your large ?: construct if you have by chance to insert a third condition (a.k.a elsif) statement? Which of both columns is better readable? Can you tell at a glance if there's a semicolon missing (or one that causes a syntax error) on a line in the left column?

--shmem

_($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                              /\_¯/(q    /
----------------------------  \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}

literally, Mr. Ternary is more on simple symbols that gives you a more concentration on expressions and statements without being bothered with words like if, elsif, and else.

Indeed: if, else, elsif are flow control constructs. ?: is an operator. Now, it happens, thanks to short circuiting and the availability of constructs that take a block and execute it, that the latter can be used in a semantically equivalent manner to the former. Yet, as has been repeatedly explained to you in this thread, they serve different purposes: there are superimpositions and there may be some situation in which the choice is not obvious. But this is generally not the case.

i don't think so that other languages could make Mr. Ternary more functional (making Mr. Ternary hold multiple-statements) than Perl could do. what do you think?

I don't understand your question, but I'll make some guess and try to answer anyway: in some functional languages, the regular branching control structures behave much like (C and) Perl's ?: in that they return a value - exactly because they're functional. But seriously, your insisting on this issue makes me think that you're simply fond of the extreme conciseness you get out of it. OTOH several different monks already explained to you the reason why we generally do not strive for extreme conciseness: Perl has already a wrongly deserved bad name for being mostly line-noise, in some circles and speaking of other languages if I were to write programs that look like brainfuck I would... program in brainfuck! But then joy the world: Perl 6 will have a grammar modifiable at runtime, so you will be free to happily brainfuck it!

They've lived together a couple of years now, and I will not let you induce quarrel amongst them over 'who is greater'!

Both serve different purposes. Mrs. If Else provides for blocks of code to be executed conditionally, whereas Mr. Ternary shortcuts them with a single statement (if they resolve to simple expressions) or delegates them elsewhere (probably to Mrs. If Else again, appearing in some sub).

They often interchange tasks, as most mordern couples do; but mostly Mr. Ternary likes to prepare hesh bugs while Mrs. If Else studies blocks of stock exchange charts to see what's best.

I'd rewrite your Mr. Ternary code like this

#!perl/bin/perl

use strict;

print "Are you sure you want to quit ('yes' or any key for 'no'): ";
chomp($_ = <STDIN>);

print /\byes\b/i ? <<LEAVE : <<STAY;

Press any key to exit...
LEAVE
Thanks, you stayed... But then, goodbye.
Press any key to proceed...
STAY
<STDIN>;
print "GOOD DAY\n";
[download]

to better show where Mr. Ternary shines - inlining a decision.

Now, to your delimma (++ alone for mispelling dilemma twice in one post :-):

In the expression

$foo = 1; $foo ? \& { print "foo"} : \& { print "bar"};
[download]

The ampersand & marks the following { } construct as a code block; the backslash disambiguates that operation from binary '&' (the bitwise AND) and returns a reference for that code block. Last, Mr. Ternary happily evaluates those references based on the 'truthness' of $foo. This is, at least, my interpretation of things, but I might be wrong. I never used that construct before...

update And I am wrong! See betterworld's comment below.

Nice post!

_($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                              /\_¯/(q    /
----------------------------  \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}

The ampersand & marks the following { } construct as a code block; the backslash disambiguates that operation from binary '&' (the bitwise AND) and returns a reference for that code block.

It's not really a code block. \&{foo} is a reference to the subroutine with the name "foo". Similarly, \& { print "foo" } is a reference to the subroutine with the name that is returned by print, i. e. it's \&1 (unless print fails).

$ perl -lwe 'my $code = \&{print "foo"}'
foo
$ perl -lwe 'my $code = \&{print "foo"}; $code->()'
foo
Undefined subroutine &main::1 called at -e line 1.
[download]

(Note that $code is not called/dereferenced in the first one-liner, yet it prints foo.

It's not really a code block. \&{foo} is a reference to the subroutine with the name "foo". Similarly, \& { print "foo" } is a reference to the subroutine with the name that is returned by print, i. e. it's \&1 (unless print fails).

Well, there's a subtle difference. When you write &{foo} -with no quotes within the curlies-, that's (almost) just as if you had written &foo. This is not specific of subs, but of quite about all kind of variables:

spock:~ [16:02:30]$ perl -wMstrict -le 'my $x=1; print ${x}'
Ambiguous use of ${x} resolved to $x at -e line 1.
1
spock:~ [16:02:36]$ perl -wMstrict -le 'my $x=1; print ${"x"}'
Can't use string ("x") as a SCALAR ref while "strict refs" in use at -
+e line 1.
[download]

hi,,, while ago i was wondering why do some programmers rarely uses the ternary operator. wherein it is less typing indeed. i believe in the classic virtue of Perl which is laziness.

I believe in that virtue too. Though the answer is the usual one: we aim for the right™ amount of conciseness, not for maximum one - except in golf that is. The ternary operator is good for what it's good for: simple branching with simple expressions, and returning a value. That it can also be used as a general purpose branching construct is a whole another matter. In particular your use of block eval's (or do's) smells mostly like a dirty hack to me. Moreover, while I often happen to use if conditions, I find that they rarely have an else block too, let alone elseif ones, courtesy of all the early loop, sub and program exit facilities available.

First of all your overuse of eval has just killed your exception reporting unless you put in a check for $@ or die. (Which your code examples didn't.) By the time you've added that, you've just made your code longer and more obscure than the original if/else construct would have. (As several have noted, you could solve that problem by using do.)

Secondly there is great value in having code with recognizable intent. For most use cases, ternary operations do not communicate intent as well as the traditional if/else. And this is not just a familiarity issue. An important principle is to put the most significant thought in the line of code first because that is what you'll notice when you're scanning through it. When you're scanning code, one of the most significant things to be aware of is the flow of control. The fact that the flow branches at an if statement is a critical fact, so you should start your line of code by communicating that fact clearly. Ternary statements don't do that, they bury the control of flow into easily missed punctuation. Occasionally this choice of emphasis is appropriate, but usually it is not.

Thirdly, it is important for programmers to work well with others. An idiosyncratic coding style is a barrier for others who want to work with you. Sure, people's styles vary. But you had better have a very good reason to pick a style that nobody else uses. And your reasons for doing that are frankly not good enough.

And finally, good programmers have to program in many different languages over the course of their careers. It is therefore wise to at least think about how well your style will work in many different languages. And the truth is that if/else style coding works appropriately in more languages than ternary operations do. Which is a reason why it is wise to use if/else whenever appropriate.

/\byes\b/i ?
do {
  ...
}
:
do {
  ...
}
[download]

maybe i missed the point of the question - but why didn't you just use do()?

Are you suggesting another way to commit the crime? Well, after all I had already suggested it myself... ;-)

Once upon a time there were compiled languages whereby subroutine parameters and indeed data referenced in the same scope could be passed around by a number of different ways: by name, by reference, by value, by descriptor being the four I know about. In a compiled language, passing by reference means simply by address instead of immediate value.

Perl has facilities for mimicking these mechanisms which I won't go into for all cases ... oh what the hell ... here goes:

by name: e.g. passing "fred" for access to $fred. This extends to anything passed literally, i.e. if you pass an expression by name, it is passed without evaluation for evaluation by whatever picks it up whereas by value it is first evaluated and then that value is passed.

by reference: this time there is no address because Perl is not a compiled language, so a Perl reference is the key in the *symbol table (see under though about Perl implementation).

by value: same as for compiled languages except that @_ is used instead of a system stack (or argument block for the case of Fortran) to pass parameters to subroutines.

by descriptor: a string descriptor for a compiled language is the starting address of two memory locations where one contained the length and the other the starting address of the string. Perl very probably uses string descriptors internally, but provides programmer access to them via the symbol table to get the string value and a length function to get at the length directly. Similarly, compiled languages sometimes have array descriptors but whereas Perl might probably uses them internally, access to them for Perl programmers is provided via the symbol table - the length of the array is in this case also symbolically accessed for Perl.

Compiled languages also use a code reference mechanism that Perl has mimicked - for compiled languages these are resolved into memory addresses by the linker - a linker takes chunks of ("object" machine) code that have symbolic references to each other and builds an image for loading whereby all the references (everything in the symbol table in fact) are resolved into relative addresses. The Perl interpreter does not do any linking but maintains code references in the (runtime) symbol table (update: compiled languages do not retain the symbol table at runtime unless a special debugging version is being compiled and linked).

Therefore ALL Perl references are "symbolic" which is a rather glib shorthand for "are maintained in the symbol table rather than using addresses in memory as references". (Update: but not all symbolic references are by name :))

(* It might be in terms of Perl implementation that there is a different symbol table implementation for different "types" - one for named and one for anonymous (in implementation, still having an internal id such as HASH + id), but however it might be split up, the collection of such implementations whether in separate structures or not is technically still "the symbol table" as far as Perl programmers can be concerned.)

If the manual were amended to (updated for readability):

"strict refs

"This generates a runtime error if you use symbolic named references (see perlref)."

update: perlref also needs to explain more clearly the distinction between named and anonymous symbolic references

Then the examples and the exception suddenly would make sense when related to the amended rule...

"There is one exception to this rule: $bar = \&{'foo'}; &$bar;is allowed so that goto &$AUTOLOAD would not break under stricture."

breaking this into pieces ... \& means taking a code reference but to get a code reference for 'foo' requires look-up by name in the symbol table. So a special exception has been made to allow named access to the symbol table even when strict refs is in force - get the rule right and at last we can see what the use of the word "exception" is all about.

__________________________________________________________________________________

Update: I would say, however, that the OP example isn't doing anything with the code references and can dispense with them. The OP example also isn't doing anything with what the terniary operator returns, so making a code reference of it doesn't do anything either and if-else is indicated. An example of where the terniary operator is indicated:

    
    my $batchsize = @ARGV && ( $ARGV[0] =~ /^-b(\d+)/ )
        ? $1
        : 1000;
[download]

printf("The answer is %s\n", defined($ans) ? $ans : "unknown");'

or

$ans = defined($ans) ? $ans : "unknown";

printf("The answer is ");
if (defined($ans))
{
    printf("%s\n", $ans);
}
else
{
    printf("unknown\n");
}

...
a := if b then c else d;
[download]

Now along comes Mr. Wall and he desires to have something that will fit his acronym for the language he is calling Perl. That begat "eval" to make expressions out of control structures. So, we can now do everything any which way we desire to make wonderful artwork out of programs that are cryptic to all.

Now comes our modern friend and he desires to keep his job (for whatever reason) and wants to do either of two things:

1) Be as cryptic as possible so he will be "indispensable" guaranteeing full employment.

2) Document all his code and make it as easy to read so he can be promoted to manager to earn more $$$.

One can do almost anything more than one way. Typically one will be "better" for the given circumstances. You will need to decide which is which. It is up to you.

hi,,, while ago i was wondering why do some programmers rarely uses the ternary operator. wherein it is less typing indeed. i believe in the classic virtue of Perl which is laziness. well let me show you something first before i go to my delimma.

I don't think the laziness virtue of Perl extends to sacrificing readability by saving to write a few characters...
I like to be able to rest my eyes on the code, without getting dizzy. ;)

I don't think the laziness virtue of Perl extends to sacrificing readability by saving to write a few characters...
I like to be able to rest my eyes on the code, without getting dizzy. ;)

I second that. In fact IMHO lazyness alone is not really a virtue. I know, because I'm so lazy!