Re: [Groff] condition: OR of two string comparisons

[Steffen Nurpmeso]

Hallo,

Carsten Kunze <address@hidden> wrote:
 |Steffen Nurpmeso <address@hidden> wrote:
 |> For S-roff i can say that yes, i'm open and want such an
 |> extension, but i will not tear up the parsers that yet exist in
 |> order to do so.
 |> I'm not yet sure but i think introducing the $ extension trigger
 |> seems to be a way to get this going, introducing some "outer
 |> state" which can be recalled once the existing parser(s) are done.
 |> 
 |> Maybe $ should be turned into a two-letter mode first, however,
 |> say $( to mean "grouping", $r "regular expression", $c the already
 |> implemented string-case thing.  That would be even better (though
 |> even uglier).
 |
 |The problem that I see is that the ".if statement" does work \
 |according the specification but not as expected for those \
 |who do not read the documentation carefully.  So I do not \

I think that ship sailed decades ago regarding the existing
constructs.
Doug McIlroy wrote not too long ago "troff lives" and that's how
it should be.

 |want do introduce a new syntax for that, just include "!" \
 |and string compare inside expressions.  Yes, the current syntax \
 |and precedence is strange, but once you are used to it it's \
 |not an issue anymore.  But the missing "!" and string compare \
 |inside expressions leads to problems which are not just comfort issues.

Ok, but i don't think that such a change will happen for S-roff,
at least not in the forseeable future, because i'd have to
completely rewrite the logic, and _that_ i wouldn't do _unless_
i'd have a _complete_ set of tests which i could run to test for
behaviour changes.  Right now groff will not parse such
parenthesized expressions via top-level .if expression checking,
but pass them down to a standalone number-specific parser which
seems to have a distinctive greediness...

On the other hand, introducing a new top-level construct, as
above, is per definition backward compatible and seems to be
possible without too much messing.  Can there be || and &&,
i haven't looked yet (especially the former may be a problem), and
not at last & and : are a choice as good as all others...
In the end such new functionality wasn't really on my list for
quite some time, so in fact i'm a bit overchallenged...

But i would prefer if the roff's could stay in sync somewhat.
Noone wins if this diverges even more.

--steffen