Re: Perlsecret - plus no-ops (updated)

with a note of : (The + is in the above line is a no-op, used to tell grep that the parentheses are not enclosing its arguments.) what does that note actually mean?

If grep is immediately followed by an opening parenthesis, that parenthesis would be interpreted as starting the argument list of grep, so for example grep( /foo/, @array ) or grep( {$_>123} @array ). However, in this case, the expression being used to search the list is "()=@$_". One could write this in the grep BLOCK LIST form of grep as grep {()=@$_} @arrays, however, in this case the author has chosen the grep EXPR, LIST form of grep. But if one wrote grep ()=@$_, @arrays, then Perl would think that you were calling grep with no arguments ("grep()"), followed by "=@$_, @arrays", which is invalid syntax. Therefore, to tell Perl that the parentheses are actually not introducing the arguments of grep, one has to disambiguate and add the + operator. Because in this case it has no effect except informing the Perl parser, it is in that sense a no-op. Another way to disambiguate the situation would have been an extra pair of parentheses, as in grep( ()=@$_, @arrays ).

This is one of the reasons that I perfer the BLOCK LIST forms of grep and map, and the same issue with parentheses commonly comes up in the arguments to print.

Typo fix in the last sentence.

Update: In this case, the use of the "Saturn" "secret" operator doesn't even really make sense, since all that is being done is that empty array references are being filtered out. This could be written as grep {@$_} @arrays (or grep @$_, @arrays), or if one wanted to be explicit that one is filtering on the number of elements the arrays contain, e.g. grep {0+@$_} @arrays.

Comment on Re: Perlsecret - plus no-ops (updated) Select or Download Code

Replies are listed 'Best First'.
Re^2: Perlsecret - plus no-ops (updated) by Anonymous Monk on Jun 23, 2022 at 19:12 UTC
I also prefer `grep BLOCK LIST` for the same reasons you give. Very occasionally, though, Perl mis-parses the left curly as introducing a hash reference constructor, and the error messages for this are far less than informative. If this happens you can force Perl to parse the left curly as a block by immediately following it by a semicolon. That is, `{; ... }`. The opposite mis-parse can also happen (Perl tries to parse a block when you wanted a hash reference). The fix for this is a unary plus before the left curly: `+{ ... }`.	[reply] [d/l] [select]
Re^2: Perlsecret - plus no-ops (updated) by Anonymous Monk on Jun 24, 2022 at 15:24 UTC
Since the goatse puts the left side in scalar context is this example the same as saying `@filled = grep {scalar @$_} @arrays;` [download] ? So interpolated for the 3rd element of array this would mean `grep {scalar 1,2} @array` [download] ?	[reply] [d/l] [select]
Re^3: Perlsecret - plus no-ops by haukex (Archbishop) on Jun 24, 2022 at 15:46 UTC
puts the left side in scalar context That's not quite right - the "operator" requires scalar context onfrom its LHS* for it to work correctly. From perlsecret (emphasis mine): It "provides a list context to its right side and returns the number of elements to its left side. Note that the left side must provide a scalar context; obviously, a list context on the left side will receive the empty list in the middle." is this example the same as saying @filled = grep {scalar @$_} @arrays; ? If by "this example" you mean the one from perlsecret, then yes, the effect is the same. `()=@$_` means to dereference the array reference that is stored in `$_`, and assign it to the empty list. And Assignment Operators says: "a list assignment in scalar context returns the number of elements produced by the expression on the right hand side of the assignment." The grep is what provides the scalar context to the `()=@$_` expression (as opposed to map, which provides list context for its expression). So interpolated for the 3rd element of array this would mean grep {scalar 1,2} @array ? No, not quite. `scalar("a","b")` causes the Comma Operator to be evaluated in scalar context, where "it evaluates its left argument, throws that value away, then evaluates its right argument and returns that value." So the aforementioned expression just returns `"b"`. This is why it's important to not use arrays of numbers when testing things like this, because `scalar(1,2)` returns a misleading result of `2` - `scalar(9,42)` returns `42`. An array in scalar context returns the number of elements it contains. So a more appropriate equivalence would be something like `scalar(@{["a","b"]})` instead, which evaluates to 2. * Update shortly after posting: Well, to be nitpicky, it's not really an operator and doesn't really have an LHS. Take the example `$n =()= "abababab" =~ /a/`, run that through `perl -MO=Deparse,-p`, and you'll see something like this, which I've edited slightly for clarity: `$n=( ()=( 'abababab'=~/a/ ) )`. So as I explained above, what is happening is that the assignment `()=...` is being evaluated in scalar context provided by the `$n=...`. A few other very minor edits.	[reply] [d/l] [select]
Re^4: Perlsecret - plus no-ops by Anonymous Monk on Jun 25, 2022 at 07:34 UTC
thanks very much for your help, but I think that I'm missing something fundamental here... isn't for the third element of `@array` `grep {@$_} @arrays` [download] yielding `grep { 1,2 } @arrays` [download] when dereferenced? and that expression is true as processed by the comma operator,so that the `[[1,2]]` array ends up in `@filtered`?	[reply] [d/l] [select]
Re^5: Perlsecret - plus no-ops by haukex (Archbishop) on Jun 25, 2022 at 07:53 UTC


Perl Monk, Perl Meditation
	PerlMonks