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

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

[Douglas McIlroy]

I think Clark was justified in deviating from Ossanna.

The prime rationale for allowing removal of read-only registers is
uniformity--a powerful argument. It simplifies documentation and
relieves a burden on users' understanding. It probably simplifies the
code, too.

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.

> 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.)

A change that I *would* welcome is warning about writing into a
read-only register. (Also make .rm work on .de--a near reversal of the
original proposal.)

Doug

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

[G. Branden Robinson]

[-- Attachment #1: Type: text/plain, Size: 5087 bytes --]

[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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]