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;
Well, if I were ever to write code like that, I'd not use "or" but ... I
can't recall this coming up. I was just commenting on Perl having the same
difference in usage of those operators.
On Fri, Jun 30, 2023 at 10:14 AM yary <not....@gmail.com> wrote:
> @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-us...@perl.org <perl6-us...@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.
>>
>
--
a
Andy Bach,
afb...@gmail.com
608 658-1890 cell
608 261-5738 wk
