Re: bad define semantics in GNU m4

[Richard Stallman]

    > Consider it a defect in GNU m4 then Akim, if it does not adhere to the
    > Single Unix Specification (IEEE Std 1003.1).  It's much like the POSIX
    > incompatibilities being fixed in bison - GNU tools are supposed to
    > _first_ implement the standards (i.e. provide viable replacements for
    > system tools) and then optionally provide additional functionality.

That is not what our policies are.  Here is what standards.texi
actually says:

    With occasional exceptions, utility programs and libraries for GNU
    should be upward compatible with those in Berkeley Unix, and upward
    compatible with Standard C if Standard C specifies their
    behavior, and upward compatible with @sc{posix} if @sc{posix} specifies
    their behavior.

    When these standards conflict, it is useful to offer compatibility
    modes for each of them.

    @cindex options for compatibility
    Standard C and @sc{posix} prohibit many kinds of extensions.  Feel
    free to make the extensions anyway, and include a @samp{--ansi},
    @samp{--posix}, or @samp{--compatible} option to turn them off.
    However, if the extension has a significant chance of breaking any real
    programs or scripts, then it is not really upward compatible.  So you
    should try to redesign its interface to make it upward compatible.

    @cindex @code{POSIXLY_CORRECT}, environment variable
    Many GNU programs suppress extensions that conflict with @sc{posix} if the
    environment variable @code{POSIXLY_CORRECT} is defined (even if it is
    defined with a null value).  Please make your program recognize this
    variable if appropriate.

In general, we look at standards as guidelines to what users may
expect or want--not as authorities to be obeyed.  To the extent that
users expect compatibility with a certain standard, it is useful to
give them what they want.  But the mere fact that something is labeled
a standard does not require us to obey it.

    On the other hand, I would like to support the standard in some
    way, perhaps changing the behaviour to match the SUS if m4 is
    invoked with --traditional, or if POSIXLY_CORRECT (hmm
    SUSLY_CORRECT...) is set in the environment?

That is a good idea.  I think that --traditional is a more convenient
interface for this particular feature.