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

[Peter Schaffter]

On Sun, Nov 23, 2014, Ralph Corderoy wrote:
> I'm fed up pointing out in different emails this is about having
> some of those new mom-using users step across into troff:

So I'm going to step into the breach.

> > The input language is the main criticism of roff today...

The *roff language has had a reputation for being thorny since the
dawn of time(2).  Remember the last entry of the "UNIX Expertise
Hierarchy"?

Wizard:
   - writes device drivers with “cat >”
   - fixes bugs by patching the binaries
   - posts his changes to Unix utilities to the net – and they work
   - can tell what question you are about to ask, and answer it
=> - writes his own troff macro packages <=
   - is on a first-name basis with Dennis, Bill, and Ken

I posit that *roff's über-geekiness nearly resulted in its death as
a player in UNIX typesetting even after James Clark released the GNU
implementation in 1990.

Aside from the conceptual difficulties presented by *roff generally
(page transitions, end-of-file handling, copy-in mode, interaction
of '.di' with running text, etc) and the terse, sometimes
idiosyncractic requests (e.g. absolute spacing that doesn't move
from the top edge of the page), the *roff language has only the most
simplistic of programming constructs.  Until '.while' got added,
there were only '.if' and '.ie/.el'.  Conditional testing of numeric
values requires an almost childish literalness; conditional testing
of strings is restricted to one-offs.

That it is possible to write complex macros with groff's limited
programming constructs does not mean the language wouldn't benefit
from some extensions and enhancements.  The chief reason for adding
them would be to bring groff into line with contemporary programming
expectations *so as to encourage development by programmers raised
with those expectations.*  I am merely paraphrasing Ralph, here.

 "If we're to have them step beyond the friendly macro package into
  doing a bit of troff, getting involved, helping keep interest going,
  perhaps specialised macros or preprocessors, or adding troff
  backends to other tools, then a nicer syntax for control flow and
  expressions would lower the hurdle."

> > ... (by users who use LaTeX or GUI tools).  Their argument
> > vanishes with a comfortable macro package.

That is true.  It's the reason for the mom macros.  In my
estimation, groff, as a complete typesetting system, is far, far too
good to be a wizards-only tool.

> > That [i.e. a comfortable macro package, ed.] can hide nearly
> > anything from the complicated low level language.  So MOM is the
> > interface to new users, not the .if statement.

The key words, above, are "nearly anything".  Nearly.  Effective use
of any macro package, including -mom, benefits from at least some
knowledge of the low-level language.  It's a point made repeatedly
in the document "Groff and mom: an overview"

  http://www.gnu.org/software/groff/groff-and-mom.pdf

Therefore, I cannot agree that '.if' is not part of the interface
when -mom is being used.  I believe the sentence is better phrased:
"So MOM is a good introduction for new users."

All this to support Ralph's position.  A nicer syntax for control
flow and expressions would not only make it easier (dare I say more
intuitive?) for users dipping into '.if' for the first time, it
would be good for the health of groff.

Speaking as a macro writer, I very much prefer the idea of a flag,
in the manner of compatibility mode, for extended conditional
testing, rather then '.iff' and friends as has been fielded.  It
leaves the 'if' request name and syntax alone, preserves backward
compatibility, and allows for easy insertion of '.if' with extended
conditional testing into existing macro packages.  I see such
a flag as being analogous to grep(1)'s -E option.

-- 
Peter Schaffter
http://www.schaffter.ca