RE: typo in accept-process-output (process.c)

[Drew Adams]

> I think a better approach is to keep using `iff' (also known as `ssi' in
> French), but to make it such that the user can click on it to get to the
> Glossary where we add an entry for it.
> We could later on use the same feature for some other terms (e.g.
> "fringe").

I agree. It is better to avoid varying the terminology for things like
this - using different terms for the same thing in different places (e.g. by
different authors). It is best to use a term such as "iff" consistently, and
define it clearly.

The meaning of "if" can vary in informal English, and different people
sometimes understand it differently. In more formal use, these are often
used as synonyms: "A implies B", "if A then B", "A only if B", "B if A", "B
whenever A", and "B provided A". And these are used as synonyms: "A if and
only if B", and "A is equivalent to B".

The problem with using "iff" is that some readers will not notice that it is
not "if", or they might think that it is a typo. If we use "iff" as Stefan
suggested, then it is important that users have a _visual_ clue that this is
a glossary term and that they can click it to see its definition. That
visual clue would be enough to signal that this is not just "if" or a typo.

Until we have such a glossary-term indicator, we should use "if and only if"
(or we could temporarily take the risk of misunderstanding and use "iff").
It is not appropriate for us to use "if" (or "only if") in place of "iff",
when the meaning of the latter is important to the context.

This is so, in spite of the fact that, as Jason pointed out, many readers
assume bidirectionality for "if"; that is, they do not distinguish "if" from
"if and only if".

In some cases, of course, the "if" direction is of primary importance, and
the "only if" case can be ignored or glossed over in the doc. That is, when
it makes little difference whether readers confuse "if" with "iff", we could
get away with using just "if". Still, in general it is better to clearly
state what happens in each case or, if they are equivalent, to use "iff" (or
"if and only if").

Because careful use of such terms can result in language that is more like a
spec than doc, it is sometimes helpful and appropriate to use both a short,
introductory, informal, easy-to-read description and a more rigorous,
detailed explanation. Those who are interested will take the time to parse
the latter, and the others will generally understand enough to get the job
done.