groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Ralph Corderoy
Subject: Re: [Groff] condition: OR of two string comparisons
Date: Fri, 21 Nov 2014 19:29:14 +0000

Hi Carsten,

> > But new users to troff, and I think Peter's MOM can attract them,
> > could well have been raised on C at best and Java at worst.  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.
> 
> The new users might not start with creating macro packages like MM.

No, they won't.  They are new users.

> They would use an existing macro package to create a document.  The
> best way to attract them is to create a comfortable macro package.

Agreed.  I suggested mom does that.

> For every purpose for using such a macro package low level requests
> like .if should not be necessary.

Oh, I think a basic .if is still useful to the novice who will probably
want to conditionally do something, e.g. "DRAFT" heading, etc.  Does mom
aim to remove the need for any non-mom-macro command, e.g. `.ds company
Google, Inc.'?

> So all this discussion here has nothing to do with attraction of new
> users, this can just be done by providing comfortable macros.  All
> this discussion is exclusively for those who create or maintain macro
> packages.

It is all about the attraction of new users because we want some of them
to move from the novice set to the intersection.  As I tried to make
clear in that paragraph you quoted, still above to re-read, this is
about getting some of those new users to step across from a macro set
with the odd trivial .if testing a number register set on the command
line to all the other things a small thriving troff community needs.

> > Here's a bit of mm picked because it uses a few `\{\'. [...]
> 
> This is an excellent argument against the new syntax.  Both macro
> syntaxes look totally equal.

Totally!?

> One looks at the statements and does not notice that \{\ is used here
> and { there.  Only one who doesn't know roff will notice this.

You've ignored two of my three points, concentrating only on you are
trained to be happy with `\{\'.  The improvements aren't aimed at you.
:-)  My points were

    Upside... I think the nicer control structures allow indentation
    that better reflects the logic structure.  Whitespace aids grokking
    expressions.  Insisting on braces and axing the backslases around
    them, even though it may trample on someone's `.{' macro, lessens
    clutter.

> And:  Compatibility has been important for you.  So .} is not
> possible.  There can't be an exception.  Else you would open doors for
> anything ....

.} clearly is possible.  Yes, it would break backwards compatibility
where it has been used as a macro name.  With every change that isn't
compatible, one must weigh up the pros and cons.  'c'a'b'c'd'e' gives
little;  it's a special one-off issue with a warty solution.  .} opens
up a big improvement IMO.

> Lets say one would take Werners .if x suggestion.  Then you could
> write
> 
> .if x (...new syntax...) \{\
> .   nr A x (...new syntax...)
> 
> Wouldn't that be sufficient?

No, because it ignores the else-if benefit to indentation, and still has
clutter, adding more for the eXtension.  How would it `x' work for .ds
rather than .nr?

I guess it, especially a preprocessor, conceivably doesn't have to use
`.' as its escape character, though I think that would be a mistake.
Unicode opens up other possibilities;  `·if'.

I'm arguing for control structures and expression syntax that's nicer to
read and easier to correctly interpret, less error-prone to write, and
doesn't frighten newcomers off.

Cheers, Ralph.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]