New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
possible inconsistency in "perlop" documentation on precedence of || and // #15280
Comments
From wolf-dietrich_moeller@t-online.deHello, In the section on “Operator Precedence and Associativity” there is the text: And further below: In the text further below in perlop these operators are listed in *separate* sections: The test program below has no grouping in line 3, but gives an explicit order of evaluation by grouping in lines 4 and 5: # test for precedence of || and // This program yields the output: This result shows that both operators in line 3 have the same precedence, as they are evaluated left-to-right (same as line 4). According to the perlop-documentation, line 3 should yield the same result as line 5 (higher precedence for “||”). My suggestion is to combine the two sections on “C-style Logical-Or” and “Logical Defined-Or” in one section, as this would clearly show that both operators have the same precedence (as implemented in Perl). I tested this issue with both Perl 5.16 and Perl 5.22, and probably it existed since the introduction of “Logical Defined-Or”. Best regards |
From zefram@fysh.orgWolf-Dietrich Moeller wrote:
The problem, such as it is, is entirely in the documentation; we should I think "covered in precedence order" doesn't require that there be only -zefram |
The RT System itself - Status changed from 'new' to 'open' |
From @SmylersWolf-Dietrich Moeller writes:
However, in-between those two parts you quoted there is also: Perl operators have the following associativity and precedence, listed followed by a table, which includes these lines: nonassoc == != <=> eq ne cmp ~~ That clearly asserts that it specifies precedence levels, and shows that
The precedence is specified, correctly, in the table you skipped over. Zefram writes:
Quite.
I think merging into a single sections could make reading and navigating If somebody wants a definition of eq or ||, they can currently be sure Smylers |
From wolf-dietrich_moeller@t-online.deSmylers writes:
These two sentences you cite are quite similar wrt expression and grammar, but you write that these sentence should *not* be interpreted in the same way. You say that the first sentence *specifies* an ordering line by line. But why is the second sentence to be interpreted in a more fuzzy way, while it has similar wording and grammar? So either these two sentences should be clarified, or both operator list and sections below should obey the *same* ordering rules. BTW, Smylers also writes:
Taking this together, it may be best to delete the reference to "precedence order" for the sections, and change the sentence below the operator list to something like "In the following sections, these operators are covered *in detail*." This would avoid wrong conclusions about precedence derived from the section list. Wolf |
From @iabynOn Mon, Apr 25, 2016 at 06:37:36PM +0200, Wolf-Dietrich Moeller (München) wrote:
If no-one objects, I'll apply the following in a few days' time: -In the following sections, these operators are covered in precedence order. -- |
From @khwilliamsonOn 06/20/2016 06:46 AM, Dave Mitchell wrote:
+1 |
From @xsawyerxOn 06/20/2016 02:46 PM, Dave Mitchell wrote:
+1. |
From @iabynOn Mon, Jun 20, 2016 at 01:46:14PM +0100, Dave Mitchell wrote:
Now done with v5.25.2-194-g3df91f1. -- |
@iabyn - Status changed from 'open' to 'pending release' |
From @khwilliamsonThank you for filing this report. You have helped make Perl better. With the release today of Perl 5.26.0, this and 210 other issues have been Perl 5.26.0 may be downloaded via: If you find that the problem persists, feel free to reopen this ticket. |
@khwilliamson - Status changed from 'pending release' to 'resolved' |
Migrated from rt.perl.org#127921 (status was 'resolved')
Searchable as RT127921$
The text was updated successfully, but these errors were encountered: