Re: A question on AND

        @a = @b || @c;              # this is wrong
        @a = scalar(@b) || @c;      # really meant this

"or" doesn't help with this either

        @a = @b or @c;              # this is wrong
        (@a = scalar(@b)) or @c;      # really meant this - @c never is
assigned to @Helen Block <[email protected]>

the low precedence and/or is was introduced in Perl 5 for this construction

open my $fh '<', $input_filename or die "Could not open $input_filename:
$!";

At $work I see bugs where people are using "or" "and" in expressions, and
the part after the expression never gets into the variable they meant it to.

my $answer = $choice_1 or $choice_2; # this is  wrong it turns into
(my $answer = $choice_1) # or $choice_2

there $choice_2 is only evaluated if the $answer got assigned a false
value, and then it gets evaluated in void context, discarding its value.

Try this in Raku - what does it say? Do you still prefer "or" over "||" ?

my $answer = 0 or 5;

say $answer;


-y


On Fri, Jun 30, 2023 at 10:53 AM Andy Bach <[email protected]>
wrote:

> I  always took [1]
>  As alternatives to "&&" and "||" when used for control flow, Perl
> provides
>     the "and" and "or" operators (see below). The short-circuit behavior is
>     identical. The precedence of "and" and "or" is much lower, however, so
>     that you can safely use them after a list operator without the need for
>     parentheses
>
> to suggest that and and or are the better ones to use and && or || should
> be used only if they're specifically needed.  Which has always been "never"
> for me.
>
> a
>
> [1]
> perldoc perlop
>    The "||", "//" and "&&" operators return the last value evaluated
> (unlike
>     C's "||" and "&&", which return 0 or 1). Thus, a reasonably portable
> way
>     to find out the home directory might be:
>
>         $home =  $ENV{HOME}
>               // $ENV{LOGDIR}
>               // (getpwuid($<))[7]
>               // die "You're homeless!\n";
>
>     In particular, this means that you shouldn't use this for selecting
>     between two aggregates for assignment:
>
>         @a = @b || @c;              # this is wrong
>         @a = scalar(@b) || @c;      # really meant this
>         @a = @b ? @b : @c;          # this works fine, though
>
>     As alternatives to "&&" and "||" when used for control flow, Perl
> provides
>     the "and" and "or" operators (see below). The short-circuit behavior is
>     identical. The precedence of "and" and "or" is much lower, however, so
>     that you can safely use them after a list operator without the need for
>     parentheses:
>
>         unlink "alpha", "beta", "gamma"
>                 or gripe(), next LINE;
>
>     With the C-style operators that would have been written like this:
>
>         unlink("alpha", "beta", "gamma")
>                 || (gripe(), next LINE);
>
>     It would be even more readable to write that this way:
>
>         unless(unlink("alpha", "beta", "gamma")) {
>             gripe();
>             next LINE;
>         }
>
>     Using "or" for assignment is unlikely to do what you want; see below.
>
> ------------------------------
> *From:* yary <[email protected]>
> *Sent:* Friday, June 30, 2023 8:45 AM
> *To:* Richard Hainsworth <[email protected]>
> *Cc:* [email protected] <[email protected]>
> *Subject:* Re: A question on AND
>
>
> *CAUTION - EXTERNAL: *
> Most of Richard's parting suggestions I understand & agree with, but not
> this: " why are you using '&&' and not 'and' "
>
> My habit (from Perl 5 days) is to use && || for expressions, and reserve
> "and" "or" for "do this if assignment/function call without parens
> succeeds/fails" – is there a refinement on that distinction in Raku which I
> should pay attention to?
>
> -y
>
>
> On Fri, Jun 30, 2023 at 5:40 AM Richard Hainsworth <[email protected]>
> wrote:
>
> I tried this and it worked without any problem.
>
> Here's the whole program:
>
> use v6.d;say @*ARGS.raku;if @*ARGS.elems > 0  &&  "@*ARGS[0]".lc eq "debug"  {
>     say 'got'}
> and at the terminal:
>
> $ raku todd-test.raku debug --debug=50
> ["debug", "--debug=50"]
> got
>
>
> FWIW
> why are you quoting ARGS? The .lc coerces to string anyway.
> why are you using && and not 'and'
> why are you not using a sub MAIN with an optional --debug
> eg. sub MAIN( @args, Bool :$debug=False) {
> #stuff
> if $debug { ... }
>
>
>
> On 30/06/2023 06:06, ToddAndMargo via perl6-users wrote:
>
> if @*ARGS.elems > 0  &&  "@*ARGS[0]".lc eq "debug"  {...}
>
> *CAUTION - EXTERNAL EMAIL:* This email originated outside the Judiciary.
> Exercise caution when opening attachments or clicking on links.
>