Follow-up Comment #1, bug #68029 (group groff): Another way to solve this problem would be to back away from GNU _troff_'s `==` extension to numeric expression syntax in the first place. (I _say_ that it's GNU _troff_'s, but it might come from SoftQuad _troff_.)
In other words, we'd always warn when hitting the thing, regardless of compatibility mode. I'd be enthusiastic to take this approach, in fact, because I think supporting `==` in _groff_ is a lame sop to C language family programmers. The *roff language family does not closely resemble C. Throwing them their preferred equality operator won't help them much because expression syntax is radically different in other ways besides--logical "or" is not spelled using the same punctuation character, *roff has zero levels of implicit operator precedence [https://en.cppreference.com/w/c/language/operator_precedence.html instead of C's 15], and so forth. (Another difference is that logical negation in *roff is hamstrung by being supported only at the beginning of an expression. C **does** compare favorably to *roff in this respect, and if we could get away with fixing GNU _troff_ to support `!` as a general logical not operator without "breaking the world", I'd be thrilled.) C screwed up by not using `:=' as an assignment operator and retaining simple `=` as an equality test operator just as everyone is taught in primary school. Sheer hubris. _______________________________________________________ Reply to this item at: <https://savannah.gnu.org/bugs/?68029> _______________________________________________ Message sent via Savannah https://savannah.gnu.org/
signature.asc
Description: PGP signature
