Develop Reference

How to make a chained comparison in Jison (or Bison)

I'm working on a expression parser made in Jison, which supports basic things like arithmetics, comparisons etc. I want to allow chained comparisons like 1 < a < 10 and x == y != z. I've already implemented the logic needed to compare multiple values, but I'm strugling with the grammar – Jison keeps grouping the comparisons like (1 < a) < 10 or x == (y != z) and I can't make it recognize the whole thing as one relation.
This is roughly the grammar I have:
expressions = e EOF
e = Number
| e + e
| e - e
| Relation %prec '=='
| ...
Relation = e RelationalOperator Relation %prec 'CHAINED'
| e RelationalOperator Relation %prec 'NONCHAINED'
RelationalOperator = '==' | '!=' | ...
(Sorry, I don't know the actual Bison syntax, I use JSON. Here's the entire source.)
The operator precedence is roughly: NONCHAINED, ==, CHAINED, + and -.
I have an action set up on e → Relation, so I need that Relation to match the whole chained comparison, not only a part of it. I tried many things, including tweaking the precedence and changing the right-recursive e RelationalOperator Relation to a left-recursive Relation RelationalOperator e, but nothing worked so far. Either the parser matches only the smallest Relation possible, or it warns me that the grammar is ambiguous.
If you decided to experiment with the program, cloning it and running these commands will get you started:
git checkout develop
yarn
yarn test

There are basically two relatively easy solutions to this problem:
Use a cascading grammar instead of precedence declarations.
This makes it relatively easy to write a grammar for chained comparison, and does not really complicate the grammar for binary operators nor for tight-binding unary operators.
You'll find examples of cascading grammars all over the place, including most programming languages. A reasonably complete example is seen in this grammar for C expressions (just look at the grammar up to constant_expression:).
One of the advantages of cascading grammars is that they let you group operators at the same precedence level into a single non-terminal, as you try to do with comparison operators and as the linked C grammar does with assignment operators. That doesn't work with precedence declarations because precedence can't "see through" a unit production; the actual token has to be visibly part of the rule with declared precedence.
Another advantage is that if you have specific parsing needs for chained operators, you can just write the rule for the chained operators accordingly; you don't have to worry about it interfering with the rest of the grammar.
However, cascading grammars don't really get unary operators right, unless the unary operators are all at the top of the precedence hierarchy. This can be seen in Python, which uses a cascading grammar and has several unary operators low in the precedence hierarchy, such as the not operator, leading to the following oddity:
>>> if False == not True: print("All is well")
File "<stdin>", line 1
if False == not True: print("All is well")
^
SyntaxError: invalid syntax
That's a syntax error because == has higher precedence than not. The cascading grammar only allows an expression to appear as the operand of an operator with lower precedence than any operator in the expression, which means that the expression not True cannot be the operand of ==. (The precedence ordering allows not a == b to be grouped as not (a == b).) That prohibition is arguably ridiculous, since there is no other possible interpretation of False == not True other than False == (not True), and the fact that the precedence ordering forbids the only possible interpretation makes the only possible interpretation a syntax error. This doesn't happen with precedence declarations, because the precedence declaration is only used if there is more than one possible parse (that is, if there is really an ambiguity).
Your grammar puts not at the top of the precedence hierarchy, although it should really share that level with unary minus rather than being above unary minus [Note 1]. So that's not an impediment to using a cascading grammar. However, I see that you also want to implement an if … then … else operator, which is syntactically a low-precedence prefix operator. So if you wanted 4 + if x then 0 else 1 to have the value 5 when x is false (rather than being a syntax error), the cascading grammar would be problematic. You might not care about this, and if you don't, that's probably the way to go.
Stick with precedence declarations and handle the chained comparison as an exception in the semantic action.
This will allow the simplest possible grammar, but it will complicate your actions a bit. To implement it, you'll want to implement the comparison operators as left-associative, and then you'll need to be able to distinguish in the semantic actions between a comparison (which is a list of expressions and comparison operators) from any other expression (which is a string). The semantic action for a comparison operator needs to either extend or create the list, depending on whether the left-hand operand is a list or a string. The semantic action for any other operator (including parenthetic grouping) and for the right-hand operand in a comparison needs to check if it has received a list, and if so compile it into a string.
Whichever of those two options you choose, you'll probably want to fix the various precedence errors in the existing grammar, some of which were already present in your upstream source (like the unary minus / not confusion mentioned above). These include:
Exponentiation is configured as left-associative, whereas it is almost universally considered a right-associative operator. Many languages also make it higher precedence than unary minus, as well, since -a2 is pretty well always read as the negative of a squared rather than the square of minus a (which would just be a squared).
I suppose you are going to ditch the ternary operator ?: in favour of your if … then … else operator. But if you leave ?: in the grammar, you should make it right associative, as it is in every language other than PHP. (And the associativity in PHP is generally recognised as a design error. See this summary.)
The not in operator is actually two token, not and in, and not has quite high precedence. And that's how it will be parsed by your grammar, with the result that 4 + 3 in (7, 8) evaluates to true (because it was grouped as (4 + 3) in (7, 8)), while 4 + 3 not in (7, 8) evaluates rather surprisingly to 5, having been grouped as 4 + (3 not in (7, 8)).
Notes
If you used a cascading precedence grammar, you'd see that only one of - not 0 and not - 0 is parseable. Of course, both are probably type violations, but that's not something the syntax should concern itself with.

Javascript operator ||0? [duplicate]

This question already has answers here:
JavaScript OR (||) variable assignment explanation
(12 answers)
Closed 5 years ago.
I'm trying to translate a Javascript function to C# when I encountered something I've never seen before:
return (a / (b - (c * G * (d || 0)))) || 0;
C# is complaining about the d || 0 portion being applied to floating point number, and I have no idea what that Javascript operator does. (in C#, it's a logical OR)
Edit: all variables are floating point numbers.

The || operator returns the expression on the left side if that expression is truthy, otherwise it returns the expression on the right side. It's commonly used like this to specify default/fallback values, for instance, when a number is expected but the provided variable might contain undefined or null. It's also commonly used when optional arguments can be passed to a function and the function want's to simply use the first one that's truthy.

|| is the "short-circuited" OR operator and in order for it to work, both operands must first be evaluated as Booleans. From left to right, the value of the first expression that can be converted to true is returned (the original value, not the converted Boolean).
JavaScript will perform an implicit conversion to determine the "truthiness" of each operand if necessary, but C# will not. A float in C# is invalid with this operator because C# is a strongly-typed language and implicit conversions do not occur. You would have to explicitly cast your float to a Boolean to be able to use this operator in C#.
In C#, you'd need:
((bool) d || 0)

|| (OR)operator works when both the operands are Boolean. If not then JavaScript tries to implicitly convert it and perform the OR operation.
You need to explicitly cast in C#.

difference between JavaScript bit-wise operator code and Python bit-wise operator code

I have converted JavaScript code which uses bit-wise operators in that code to Python code, but there is one problem when i do this in JavaScript and Python
412287 << 10
then I get this 422181888 same results in both languages. but when i do this in both
424970184 << 10
then i get different results in both of the languages 1377771520 in JavaScript and 435169468416 in Python
can anybody help me with this?
any help would be appreciated.

If you want the JavaScript equivalent value then what you can do is :
import ctypes
print(ctypes.c_int(424970184 << 10 ^ 0).value)
Output:
1377771520

As stated in this SO answer, in javascript the bitwise operators and shift operators operate on 32-bit ints, and your second example overflows the 32 bit capacity, so the python equivalent would be:
(424970184 << 10) & 0x7FFFFFFF
(you get a "modulo"/"masked" value with the signed 32 bit integer mask, not the actual value)
In Python there's no limit in capacity for integers, so you get the actual value.

Bitwise Assignment Operator for Boolean instead of Longer Expression ( |= operator)

Question
A friend of mine is asking whether he could use:
result |= condition
Instead of:
result = result || condition
in javascript, for boolean operations.
I'm well aware that one is bitwise and the other is logical.
However, what would be the effect on boolean variables?
I'm not currently in front of my computer but also wondering if there could be such a thing as a ||= operator.
Update
I just realized that a boolean value is essentialy a 1 bit value. Does this mean that for booleans the logical or has the same as the bitewise or ?
So a|=b would be equivalent to a=a|b ?

Does this mean that for booleans the logical or has the same as the bitewise or ?
In your case, somewhat.
When using logical expressions, operands may either be true-ish or false-ish. An OR-expression here returns the first one that is true-ish (not necessarily the boolean true), or if none is, the last operand.
result || condition
Returns result if result is true-ish, otherwise condition
When using bitwise expressions, operands are signed 32 bit integers. If you limit that to one bit, this somewhat resembles the behaviour of logical expressions: If one bit is set, an OR-expression returns 1.
result | condition
Returns a signed 32 bit integer with a value of 0 or 1 for operands convertible to a 32bit integer with only the least significant bit used.
However, when using bitwise expressions on operands that are not a 32 bit integer, implicit conversions to 32 bit integers have to be performed and there might be additional edge cases. I'd not recommend using bitwise expressions for logical operands.

Unexpected use of '>>>' in cross-browser split

I put cross-browser split into my code and run it through jsHint and got Unexpected use of '>>>' in lines:
limit = limit === undef ?
-1 >>> 0 : // Math.pow(2, 32) - 1
limit >>> 0; // ToUint32(limit)
the same is when I put it in one line and also put expressions into parentheses
is this error? How can I fix it?

You can disable the error (well, they really should call it a warning) by turning off the "When bitwise operators are used" option (the top option listed here — oddly, the documentation doesn't mention all of the bitwise operators it relates to); if you do, the code above doesn't produce an error.
Here's the rationale for warning about the use of bitwise operators from the original JSLint tool (JSHint is a friendlier version of JSLint with more options to turn off "errors" that are purely style):
Bitwise Operators
JavaScript does not have an integer type, but it does have bitwise operators. The bitwise operators convert their operands from floating point to integers and back, so they are not as efficient as in C or other languages. They are rarely useful in browser applications. The similarity to the logical operators can mask some programming errors. The bitwise option allows the use of these operators: << >> >>> ~ & |.