Skip to content
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

Clarify operator precedence description and table #4031

Merged
merged 1 commit into from
Feb 12, 2022
Merged

Clarify operator precedence description and table #4031

merged 1 commit into from
Feb 12, 2022

Conversation

codesections
Copy link
Collaborator

This PR clarifies the operator precedence table (as discussed in #4029) and clarifies/expands the accompanying discussion of operator precedence and associativity.

This PR makes the following changes:

  • In the operators table, replaced the column that contained L, R, N, C, and X with a column listing associativites of 'left', 'right',
    'non', 'chain', and 'list'. These single-letter abbreviations were used in S03, but are not currently used in elsewhere in Raku/Rakudo/the docs other than in a table in language/functions.
  • Made corresponding changes to the language/functions table.
  • Split the discussion of precedence and associativity into separate subsections for clarity.
  • Marked precedence levels that do not currently have any operator subroutines (these mostly do have operators, but those operators are special-cased by the compiler and aren't accessible to users).
  • Slightly expanded the associativity table and changed the example infix operator from ! to § to avoid confusion with prefix:<!>.
  • Added a brief discussion of how associativity applies to non-infix operators and a note that setting the associativity for non-infix operators is NYI (see "unary" is not a description of associativity  rakudo/rakudo#4779, Custom postcircumfix operators silently ignore precedence/associativity traits rakudo/rakudo#4780).
  • Removed the table depicting associativity between unary operators, which misleadingly implied that creating right-associative unary operators is possible. (I commented out the table rather than deleting it so that we can add it back if/when custom assoc is implemented for unary ops.

So, as I guess I should expect by now, a seemingly simple doc update grew into a more significant change than I expected, led me to realize I didn't understand something as well as I thought, and led me into an edge case that triggers a Raku bug! But, on the other hand, it also put me on the path to solving that bug – and it's one that's been around since 2014, so at least there's that 😁

This commit clarifies the operator precedence table as discussed in
#4029 and the accompanying discussion of operator precedence
and associativity.

The commit made the following changes:
 * In the operators table, replaced the column that contained L, R, N,
   C, and X with a column listing associativites of 'left', 'right',
   'non', 'chain', and 'list'.  These single-letter abbreviations were
   used in S03, but are not currently used in elsewhere in
   Raku/Rakudo/the docs other than in a table in `language/functions`.
 * Made corresponding changes to the `language/functions` table.
 * Split the discussion of precedence and associativity into separate
   subsections for clarity.
 * Marked precedence levels that do not currently have any operator
   subroutines (these mostly do have *operators*, but those operators
   are special-cased by the compiler and aren't accessible to users).
 * Slightly expanded the associativity table and changed the example
   infix operator from `!` to `§` to avoid confusion with
   `prefix:<!>`.
 * Added a brief discussion of how associativity applies to non-infix
   operators and a note that setting the associativity for non-infix
   operators is NYI (see rakudo/rakudo#4779, rakudo/rakudo#4780).
 * Removed the table depicting associativity between unary operators,
   which misleadingly implied that creating right-associative unary
   operators is possible.
Copy link
Contributor

@JJ JJ left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very valuable. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants