The nearest I could get is the nested ternaries.

I'd never done this before today but you can use do to achieve the Haskell effect. The do block evaluates to the last expression evaluated.

for my $i (1..2)
{
  my $v = do {
    if ($i == 1)
    {
      "one";
    }
    else
    {
      "not one";
    }
  };
  print "i = $i, v = $v\n";
}
[download]

So which is more reabable?

$v = do {if ($i == 1) { "one" } else { "not one" };
$v = $i == 1 ? "one" : "not one";
[download]

The worry I have about the Haskell way is that it's very easy to accidentally evaluate something else after the if and muck it all up (of this doesn't apply to actual Haskell, just Perl)

That's quite clever, but that is what I would classify as a 'trick' on the basis that if else elsif are designed conditional invocation of blocks of code.

The ternary is specifically designed for conditional assignment of values. Not many people baulk at using

my $min = ( $x < $min ) ? $x : $min;
[download]

. The only problem here is that there are two conditions instead of one, requiring the use of chained ternaries. But then, noone baulks at using nested or chained ifs, and the structure of the code is identical.

And is it really any clearer?

#! perl -slw
use strict;

for ( 1 .. 3 ) {
    print do{
        if( $_ == 1 ) { 'one' }
        elsif( $_ == 2 ) { 'two' }
        else{ 'three' }
    };

    print $_ == 1 ? 'one'
        : $_ == 2 ? 'two'
        : 'three';
}
[download]

To my eyes, the former is not even slightly clearer than the latter, but then I use this construct freely, when applicable and so I am used to seeing it and it presents me with no problems to read it. Especially if it is formatted well.

Indeed. The only reason why some of Perl's more obscure contructs are eshewed by some, is because they are obscure. It's a self-propogating argument. If more people used them, they would less obscure--more familiar--and the reason for not using them diminishes.

I'd go even further and say that using the appropriate operators for the operation has further benefits:

1. It prevents the confabulations of program logic.

   By this I mean that it forces a separation between different operations in a way that clarifies the code.

   Example: Given the code:

   my $var;
   if( <cond1> ) {
       $var =  <somevalue>;
   }
   elsif( <cond2> ) {
       $var = <someothervalue>;
   }
   else {
       $var = <default>;
   }
   [download]

   A spec change or bug fix results in this modification:

   my $var;
   if( <cond1> ) {
       $var =  <somevalue>;
       doSomething;
   }
   elsif( <cond2> ) {
       $var = <someothervalue>;
       doSomethingElse;
   }
   else {
       $var = <default>;
   }
   [download]

   I would much rather see that coded as:

   my $var = <cond1> ? <somevalue>
           : <cond2> ? <someothervalue>
           : <default>;
   
   doSomething     if $var == <somevalue>;
   doSomethingElse if $var == <someothervalue>;
   [download]

   To me, it much more clearly captures the semantics of the code.

2. It provides less opportunities for someone to come along and interperse code performing unrelated notions into the conditional blocks.
3. To a certain extent, even the fact that it may force later visitors to the code to actually read the code, rather than just scanning it, is itself a plus.

   I'm as guilty as the next man, perhaps more so, of scanning a piece of code and seeing what I think it does instead of what it actually does. If code that does conditional assignment to a variable, looks like an assignment to a variable (with conditions)

   my $var = ......;
   [download]

   , That is more likely to register as that than if it looks like a declaration of a variable followed by a set of conditional blocks of code:

   my $var;
   
   if( ...  ) {
       $var =  ...;
   }
   elseif( ... ) {
       $var = ...;
   }
   else {
      $var = ...;
   }
   [download]

   Where the primary purpose of the code is lost in it's construction.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?

"Science is about questioning the status quo. Questioning authority".

The "good enough" maybe good enough for the now, and perfection maybe unobtainable, but that should not preclude us from striving for perfection, when time, circumstance or desire allow.

I'm not really recommending it as a good idea, just pointing out that it can be done and is pretty much the direct translation of cond. That said, the problem with doing other stuff in the blocks only arises when you leave the realms functional programming and start using side-effects (and in fact mixing side effect with returning values).

I just tried something interesting:

my ($x, $y) = (0,0);
for my $i (1..2)
{
  do {
    if ($i == 1)
    {
      $x;
    }
    else
    {
      $y;
    }
  } = 7;
  print "i = $i, x = $x, y = $y\n";
}
[download]

This doesn't work but it would have worked with an lvalue sub so why not allow lvalue do blocks.