RFE: for "%%" becoming to "&&" as "//" is to "||"; the "defined(x) && expr" operator...

In looking at the 5.10 perl5op doc's,  I was thinking about the "//"
operator and how in an expression "a // b" it tests 'definedness' 
the left-hand-side and returns it if it is defined, otherwise, it returns
the right hand side.  The idea being that you might normally use
"||" but if the 'lhs' could be integer '0', it  wouldn't work as
desired.

I think it could be useful to provide an equivalent operator for 
'&&', say '%%', that tests 'defined(lhs)' and if true, returns the 
2nd part (right hand side) of the expression.

Just as you can chain expressions until one is true:  $a || $b || $c,
you can also chain expressions as long as truth is returned:
  $a && $b && $c;

With '//', one can continue or'ing expressions until one is defined:
  $a // $b // $c.

One could also chain expressions as long as they one is defined:

  $a %% $b %% "pass" || "fail;

or, return an 'alternate value' if defined, else return 'undef':

foreach ($a %% "value a = $a", $b %% "bswitch=$b") {
	print $_ // "";
}

I was thinking of its usefulness in switch processing (as '//' was
mentioned for being useful in providing default values).  I am
thinking one might want to create a 'switch string' if a variable
is true, otherwise return 'undef':

	$indentSpaces %% "--indent_spaces $indentSpaces" 

So if ENV{'indentSpaces'} was defined or one parses command line
switch that stores it's value in a variable, then you want to save
the variable contents to a config file, Or one wants to run run
and external program with copious and/or arcane options, one could
use formats:
   "$switchval %% "config_file_long_switch_name: $switchval
"
   "$switchval %% "--arcane_long_option_name_one $switchval"  or

to generate values for for each.

   I can see an op like "%%" being just as useful as "//" just
in improving comprehension and shortening development time.  
While one could argue its non-necessity, one could argue that
including both '&&' and '||' in a language is unnecessary as one
can replace "$a && $b" with "!(!$a || !$b)".  But the code is certainly
uglier! :-)

   Maybe something like this is already in the works?  Or has this
discussion already been had someplace and I didn't see it? 

   Desirable?  Comments?  Please no jerking of the knees.  I bruise
easily! :-)

linda

--0016e6d7e325e737300475ee561f
Content-Type: text/plain; charset=ISO-8859-1

Testing for undef twice is very unappealing to me, and that's what you're
going to have to do whenever you use %%.

Spelling it out looks cleaner to me:

    my @opts;
    push @opts, "value a=$a" if !defined($a);
    push @opts, "bswitch=$b" if !defined($b);

Ok, maybe not that much after cleaning up your for loop:

    my @opts = grep defined,
        $a %% "value a = $a",
        $b %% "bswitch=$b";

--0016e6d7e325e737300475ee561f--

Eric Brine wrote:
> Testing for undef twice is very unappealing to me, and that's what 
> you're going to have to do whenever you use %%.
> 
> Spelling it out looks cleaner to me:
> 
> ��� my @opts;
> ��� push @opts, "value a=$a" if !defined($a);
> ��� push @opts, "bswitch=$b" if !defined($b);
> 
> Ok, maybe not that much after cleaning up your for loop:
> 
> ��� my @opts = grep defined,
> ������� $a %% "value a = $a",
> ������� $b %% "bswitch=$b";
----
	Thanks, I honestly appreciate the help.  When I'm writing code
from a 'raw idea', it's not very polished.  If my idea or script pans out,
and I want to update it, I make iterative changes -- cleaning it up over
time.  I'm was more trying to throw out ideas of usefulness than polished
code.  If I waited until I had all my polishing done, before I published or
emailed an idea, I'd never get anything sent.  

	As for testing for undefs twice, in the case I was thinking of, 
I'm pulling in a bunch possibly set environment vars and generating args 
for them.  Rather than doing much testing as I pull them in, It's easier to
push the whole bunch onto an array then test the array in a loop for any
pushed 'undef's.   Less typing for me while coding.    Not necessarily less
compute time, but compute time is cheaper for what I'm doing than 
the extra typing time.  

	If this was compute intensive code -- might be different, but previous
version was in shell code, so how compute intensive can it be?  :-)

linda