Hacker News new | past | comments | ask | show | jobs | submit login

I was thinking `NOT (1|2)` and `NOT () 2` could make sense if the parser just has a `not_in_effect` flag that gets set to true when a `NOT` is encountered and then applies to the next integer as soon as one is parsed. So `NOT (1|2)` sets the flag, then starts parsing `(1|2)`. Once it's parsed the `1`, it notices a NOT is in effect so it applies it to the 1 as if it had just parsed `NOT 1` (which leaves 0 unchanged), then parses `| 2`, so the result is 2.

`NOT () 2` would be the same logic. `)` signifies the end of an expression and thus evaluates to the current integral result, which is 0 (for the same reason that unary - is zero), and a NOT is in effect so it's treated as `NOT 0` which is a no-op ("unset no bits"). Then the next `2` makes the result `2`. This assumes that `x y` is parsed the same as `x | y` (maybe only if a `NOT` has been parsed at any point first) or as `y` (the same stack-like "the last number that was parsed becomes the result" behavior described in other items).

This doesn't explain the `7 NOT NOT 4 NOT 2 NOT NOT 1 = 2` case though. If the parser just *sets* the `not_in_effect` flag when it encounters a `NOT` (instead of *toggling* it), then this would be `7 | NOT 4 | NOT 2 | NOT 1` which would be 0. If the parser does toggle the flag, this would be `7 | 4 | NOT 2 | 1` which would be 1 or 5. If the parser treats a `NOT` as ending the previous expression (if any), this would be `7 | NOT 0 | NOT 4 | NOT 2 | NOT 0 | NOT 1` which would be 0.






Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: