🚀 go-pugleaf

In article <1435@vidiot.UUCP> brown@vidiot.UUCP (Vidiot) writes:
 > In article <1434@vidiot.UUCP> brown@vidiot.UUCP (Vidiot) writes:
 > <
 > <I am running ISC 2.0.2 Unix and ISC text processing package.  When I have
 > <the following line, with neither of the registers set on the command line:
 > <
 > <	.if \nG==1&\nI==0 \{\
 > <	.tm inside coverdef G=\nG I=\nI
 > <
 > <It gets past the if statement and shows that both registers are indeed zero.
 > <
 > <If I change the order of the test, like this:
 > <
 > <	.if \nI==0&\nG==1 \{\
 > <	.tm inside coverdef G=\nG I=\nI
 > <
 > <It doesn't get to the next statement, just as I would expect.  If I do -rG1
 > <on the command line, then it gets past the if statement, as I expected.
 > <
 > <What the Hell is going on here?  Is the ISC version of DWB 2.0 broke?

Remember that famous line from the manual: ``evaluation is from left
to right''? So in this case, the & doesn't take precedence over the ==
as it would in C (if (G == 1 && I == 0)

What you want to do, is to put the test in paratheses as in

	.if (nG==1)&(\nI==0) .tm condition is true

 > 
 > As it turns out, groff 1.00 does the same thing.  Why is the order of testing
 > important?
 > 

Groff is correctly implementating the left-to-right evaluation
rule. Anyway, a lot of people forget about this so they resort to

	.if \nI==0 .if \nG==1

Common idiom in a macro pacakge is:

	.if !\nI .if \nG .tm true

which is actually a different test (in C: if( I != 0 && G == 0) )


	jaap


PS. I assume that you know that you have to double the backslahes
inside a macro. I guess you didn't want to shoe all these trivial
details.