[TUHS] Any reason the removal/renaming of read-only registers should be permitted?

Thu May 4 00:29:13 AEST 2023

[adding groff to CC list since this is a reply to a message I posted
there]

Hi Doug,

Thank you for your considered response.

At 2023-05-03T09:07:03-0400, Douglas McIlroy wrote:
> I think Clark was justified in deviating from Ossanna.
> 
> The prime rationale for allowing removal of read-only registers is
> uniformity--a powerful argument.

Fair, and this occurred to me too.

> It simplifies documentation

This, I would quibble with.  I feel morally compelled to document this
as one of many differences from AT&T troff.  On the bright side, in
groff documentation, those considerations are for the most part confined
to dedicated sections that the newcomer or other user without mastery of
the AT&T troff dialect easily can pass over.  (And a good thing, as
those portions of the documentation have grown measurably since I
started contributing, mainly to document differences that have been in
place for many years.[1])

> and relieves a burden on users' understanding.

True, except for the grumbling grognards we're familiar with who fixed
their understanding in place many years ago and resist developing it.

> It probably simplifies the code, too.

Assuredly that.  In reviewing the class hierarchy for registers in
groff, I see that I would at the very least need to add a virtual
member function `locked` to an abstract base class.  Or possibly
reorganize the class hierarchy to add a new layer.  I had not decided
upon a course yet, because I found some logically prior cleanups that I
wanted to do first.

> This kind of special-casing is AI in the service of some perception
> that "no one would want to do that.". If "that" is the clear meaning
> of some specified action, then so be it. We are not dealing with
> physical hazards here.

I would agree that if someone can screw up the formatter's state by
deleting a read-only register, then that bit of state was improperly
shielded from the *roff language interface in the first place.

And to be fair, I haven't yet found any evidence of such.  To take an
easily understood example, you can blow macro packages and documents to
holy hell by removing the `.l` register if they blithely assume they can
get the truth from it, but the formatter still knows what the line
length is.

$ cat EXPERIMENTS/remove-.l-register.roff
.de XX
foo bar baz qux
.br
..
.ll 8n
.tm .l=\n(.l
.XX
.rr .l
.tm .l=\n(.l
.XX
.ll +2n
.XX
.ll -2n
.XX
.pl \n(nlu
$ cat out
foo  bar
baz qux
foo  bar
baz qux
foo    bar
baz qux
foo  bar
baz qux
$ cat err
.l=192
.l=troff: backtrace: file 'EXPERIMENTS/remove-.l-register.roff':9
troff:EXPERIMENTS/remove-.l-register.roff:9: warning: register '.l' not defined
0

DWB 3.3 nroff stdout is the same.

> > even if they don't screw up the formatter internally,
> > they will become unrecoverably useless for documents
> > and macro packages,
> 
> The same argument could be made about \applying .rm to any standard
> request, and I would disagree for the same reason as above. (A
> disappointing experimental discovery in this regard: .de seems to be
> immune to removal.)

I have good news for you!  Removing `de` seems to work just fine for me
in groff 1.22.4 and Git.

$ nl EXPERIMENTS/remove-de-request.roff
     1  .de A
     2  foo
     3  ..
     4  .rm de
     5  .de B
     6  bar
     7  ..
     8  .B
     9  .pl \n(nlu
$ nroff -ww EXPERIMENTS/remove-de-request.roff
troff: EXPERIMENTS/remove-de-request.roff:5: warning: macro 'de' not defined
troff: EXPERIMENTS/remove-de-request.roff:7: warning: macro '.' not defined
troff: EXPERIMENTS/remove-de-request.roff:8: warning: macro 'B' not defined
bar

> A change that I *would* welcome is warning about writing into a
> read-only register.

Already done, and since I didn't add it, probably extant in groff for a
long time.

$ echo '.nr .l 80n' | nroff
troff: <standard input>:1: can't write read-only register

This bit of tomfoolery was not overlooked, either:

$ echo '.af .l I' | nroff
troff: <standard input>:1: can't alter format of read-only register

> (Also make .rm work on .de--a near reversal of the original proposal.)

groff might conform to your expectations better than you thought it did.

I observe that no one seems to have ever complained about, or even
noted, this GNU troff difference from AT&T.

I do think groff's documentation could benefit from a warning to the
callow that destruction of predefined requests, registers, and (one)
string is an irreversible process.

I will shelve this reactionary idea for the indefinite future, then.  As
an anti-reactionary by temperament, that suits me down to the ground. ;)

Regards,
Branden

[1] The exception being the change, forthcoming in groff 1.23.0,[2] to
    to the interpretation of `\s11`, `\s24`, `\s36`, and similar.

    https://git.savannah.gnu.org/cgit/groff.git/tree/NEWS?h=1.23.0.rc4#n35

[2] Now at release candidate 4!  Try it today!

    https://lists.gnu.org/archive/html/groff/2023-04/msg00135.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://www.tuhs.org/pipermail/tuhs/attachments/20230503/f3bbfc07/attachment-0001.sig>