@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 <amazingly...@hotmail.com>
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 <andy_b...@wiwb.uscourts.gov>
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 <not....@gmail.com>
> *Sent:* Friday, June 30, 2023 8:45 AM
> *To:* Richard Hainsworth <rnhainswo...@gmail.com>
> *Cc:* perl6-users@perl.org <perl6-users@perl.org>
> *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 <rnhainswo...@gmail.com>
> 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.
>
