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: Carsten Kunze
Subject: Re: [Groff] condition: OR of two string comparisons
Date: Wed, 19 Nov 2014 07:46:55 +0100 (CET)

address@hidden wrote:

> Is this a standard? (.ifg == .if g, .ifq == .if q, ..)

Only in compatibility mode.  In default groff mode it is not the same.

> .iff doesn't exists, doesn't it?

It is discussed as one possibility to be implemented.

> .if o and .ifo isn't implemented neither.    ??

.if o ??? I think it is.

What is .ifo?

> Long identifiers (.ifx) are a generally used syntax to show that it
> is not original AT&T?

At least that ensures compatibility.

> .if x  versu  .ifx

I think you did not read the thread carefully.  .iff is suggested to ensure 
compatibility when implementing the new condition syntax.

> > name it .iff.  Or do you talk about that .iff and .if is used?  It
> > should be clear that .iff expects a different condition syntax
> > than .if.
> 
> It should? By what?

By specification :-)

> is not that clear. So one will not stringently expect that .if
> and .ifx is of the same class of requests. But that is evident for
> .if x and .if.

It will be specified.  If one does not know of .iff and uses .if everything is 
fine.  If a new request name is used for the new syntax compatibility is 
inhernetly ensured.  Again--please read the full thread.

> > Anyway users of macro packages (mom, me, mm, ms, man, mdoc etc.)
> > should not need conditional statements.  So all that here is for very
> > few users how design macro packages.  Do *they* really need all that
> > comfort that goes beyond .iff?  I don't understand it.
> 
> Despite you don't support your claims with evidence, this is free
> software, don't have to tell me what to do, reading the thread shows
> otherwise and at least, you are discriminating me!

This has nothing to do with you.  There is a limitation in conditionals since 
more than 40 years (there may have been good reason for implementing it this 
way).  This limitation could just be removed.  There is a theoretical 
possibility that this would introduce incompatibility but it's very unlikely.

The current suggestions just goes much too far.  Two syntaxes for one thing 
looks cluttered and like a kludge.  This is not evolution which fits to the 
existing language.

I don't tell you anything, this is just a discussion.

Carsten



reply via email to

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