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
