Re: A question on AND

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 <[email protected]> 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 <[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.
>>
>

-- 

a

Andy Bach,
[email protected]
608 658-1890 cell
608 261-5738 wk