Re: [Groff] MM's nested lists: AL inside BVL

[Ted Harding]

On 27-Jun-10 19:39:54, Anton Shepelev wrote:
> Hello all,
> I  think,  although it is not explicitly documented,
> it is inferrable from  the  desctiprion  of  the  \n
> escape:
> 
>   Interpolate  number  register  with  name  IDENT
>   (one-character name I, two-character  name  ID).
>   This  means  that  the  value of the register is
>   expanded in-place while gtroff  is  parsing  the
>   input  line.  Nested  assignments  (also  called
>   indirect assignments) are possible.
> 
>   [Then some examples follow  which  it  might  be
>   useful  to  supplement with a sample of the dis-
>   cussed behaviour...]

Yes, that description does imply this behaviour (or at least
suggests it ... )! I have also gone back to some old printed
UNIX documentation which I have, and in the 1976 "Nroff/Troff
User's Manual -- Reference Manual", section 8, it is stated:
"... a number register cab be ... interpolated into the input
in a variety of formats." and, later: "When interpolated,
a number register is converted into decimal (default), decimal
with leading zeros, lower-case Roman, upper-case Roman, lower-
case sequential alphabetic, or upper-case sequential alphabetic,
according to the format specified by 'af'."

Now that certainly implies that the register is read out as
characters, at any rate when it is being interpolated into
text material. I think where the obscurity or confusion may arise
is that one might expect that when used in a numerical context
(e.g. ".nr X \nY") its numerical value would be used. However,
once one realises that when troff encounters a line like ".nr X \nY"
it is reading input, and therefore will (presumably ... ) extract
the contents of Y as characters, even if the number in Y is being
stored as a binary integer. The following seems to confirm this:

nroff << EOT
> .nr X 9
> .nr Y (8-9)
> .af Y I                \"UC Roman
> The value of Y is \nY
> .br
> .nr X \nY
> The value of X is \nX
> EOT
<standard input>:6: warning: numeric expression expected (got `I')
The value of Y is -I
The value of X is 9

So '\nY' was output both into the text, and also into ".nr X \nY",
as "-I", using the upper-case Roman format (and the value of \nX
was not changed).

> Now that the reader knows that \n  performs  textual
> expantion, it is logical how the assgnment of a neg-
> ative value can turn into a decrement.
> 
> My humble opinion is that such behaviour is asymmet-
> rical (decrement for negative values, but assignment
> for positive ones) and not evident  form  the  first
> sight,  and  that  it could be changed by delegating
> the  increment/decrement  operation  to  a  separate
> request (like .ir).

That -- the asymmetry -- is also my feeling exactly! However,
I think the increment/decrement operation is best left alone!
Consider:

nroff << EOT
> .nr X 9
> .nr Y (-1)
> .nr X \nY
> The value of X is \nX
> .br
> .nr X +\nY
> The value of X is \nX
> .br
> .nr Y 10
> .nr X +\nY
> The value of X is \nX
> EOT
The value of X is 8
The value of X is 7
The value of X is 17

So, provided the "\nY" is preceded by "+" as in ".nr X +\nY",
the increment will take place appropriately whatever the sign
of \nY -- a decrement if the sign is negative. So, if you want
to use \nY in this increment/decrement way, you can use the "+"
prefix. And, of course, if you do not want an "accidental"
decrement in an assignment, when \nY is negative, you can
bracket it: ".nr X (\nY)".

And, while you're at it, you might as well always bracket it
since the "+" prefix will still work as before with the brackets,
if that's what you want to do:

nroff << EOT
> .nr X 9
> .nr Y (8-9)
> .nr X +(\nY)
> The value of X is \nX
> EOT
The value of X is 8

and assignments ".nr X (\nY)" will always be safe.

> Yes, this will render all existing sources incompat-
> ible and require their authors to replace all decre-
> ments and increments with the new escape :P
> 
> Anton

Lovely!
Ted.

--------------------------------------------------------------------
E-Mail: (Ted Harding) <address@hidden>
Fax-to-email: +44 (0)870 094 0861
Date: 27-Jun-10                                       Time: 23:07:05
------------------------------ XFMail ------------------------------