In the generators for library blocks, some of the ORDER enums used are incorrect.
Context
We specify operator precedence (ORDER) in 2 types of places:
When calling valueToCode to get the value of an input (strongest operator that could split the returned code)
When returning generated code for a value block (weakest operator that the final block of code could split at)
Example of issues
In some cases, the mistake in order has no side effects or only causes extra parenthesis. These mistakes are only a problem for when looking at code for examples. This happens in the following instances:
if using an order for an operator stronger than the actual one for max strength (passed to valueToCode)
if returning an order for an operator weaker than the actual one for min strength (for generator return)
Certain swaps of orders don't cause issues because of how close they are in order (ex: commonly mixed up ORDER_MEMBER and ORDER_FUNCTION_CALL don't cause any side effects)
In other cases, the mistake in order causes syntax error in specific edge cases. This can be very tricky to catch because there are a lot of valid combinations.
Expected behavior
Library blocks should use the correct order:
There should be no syntax errors in code generated from Blockly blocks.
In the case where the mistakes don't cause syntax errors, mistakes in order are detrimental to others' understanding of generators and make the code unsuitable as example code.
Current progress
Generator code reviewed/fixed (for all languages):
[x] colour
[ ] list
[ ] logic
[ ] loops
[ ] math
[ ] procedures
[x] text
[ ] variables
[ ] variables_dynamic
Additional context
Historically, there has been a lot of confusion with understanding the correct operator precedence to use when writing generator code. Part of what contributes to this confusion is that the value of the ORDER enums is inversely related to the strength (higher order and stronger precedence is a lower value).
Describe the bug
In the generators for library blocks, some of the
ORDER
enums used are incorrect.Context
We specify operator precedence (
ORDER
) in 2 types of places:Example of issues
In some cases, the mistake in order has no side effects or only causes extra parenthesis. These mistakes are only a problem for when looking at code for examples. This happens in the following instances:
ORDER_MEMBER
andORDER_FUNCTION_CALL
don't cause any side effects)In other cases, the mistake in order causes syntax error in specific edge cases. This can be very tricky to catch because there are a lot of valid combinations.
Expected behavior
Library blocks should use the correct order:
Current progress
Generator code reviewed/fixed (for all languages):
Additional context
Historically, there has been a lot of confusion with understanding the correct operator precedence to use when writing generator code. Part of what contributes to this confusion is that the value of the
ORDER
enums is inversely related to the strength (higher order and stronger precedence is a lower value).