nonuniform behavior of builtins

--000000000000147aa20621caab73
Content-Type: text/plain; charset="UTF-8"

It is annoying that various builtin macros don't argument lists like
ordinary macros do.

dnl complains if given an argument list--even an empty one. info m4 has a
long discussion about how dnl treats arguments, even though the treatment
is exactly the same as for non-builtin macros. When the argument list is
empty, the diagnostic wrongly says there are too many arguments. When
arguments are present, they are collected and never used, just as happens
for extra arguments for any macro call. Why should dnl care, when ordinary
macros don't? The diagnostic is just plain silly.

undefine is not recognized (i.e. it is copied to the output) when it lacks
an argument list. undefine(), however, is recognized and does nothing--the
expected limiting behavior. Ordinary macros treat a missing argument list
as an empty list. undefine's special behavior adds complexity to m4 and its
documentation for no apparent reason.

Option -G does not affect either of these behaviors. I find it hard to
believe that either Kernighan or Ritchie would perpetrate such
nonuniformity. Does anybody know whether it has any historical
justification?

Several other builtins share undefine's anomalous behavior for a missing
argument list. Again, special behavior entails extra documentation for each
such builtin.

I think the dnl diagnostic should be canned. I also lament the nonuniform
treatment of missing argument lists, and suggest it be phased out: when
undefine and its ilk are copied to output warn that the bevior is scheduled
to change.

Doug McIlroy

--000000000000147aa20621caab73
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">It is annoying that various builtin macros don&#39;t argum=
ent lists like ordinary macros do.<div><br></div><div>dnl complains if give=
n an argument list--even an empty one. info m4 has a long discussion about =
how dnl treats arguments, even though the treatment is exactly the same as =
for non-builtin macros. When the argument list is empty, the diagnostic wro=
ngly says there are too many arguments. When arguments are present, they ar=
e collected and never used, just as happens for extra arguments for any mac=
ro call. Why should dnl care, when ordinary macros don&#39;t? The diagnosti=
c is just plain silly.</div><div><br></div><div>undefine is not recognized =
(i.e. it is copied to the output) when it lacks an argument list. undefine(=
), however, is recognized and does nothing--the expected limiting behavior.=
 Ordinary macros treat a missing argument list as an empty list. undefine&#=
39;s special behavior adds complexity to m4 and its documentation for no ap=
parent reason.</div><div><br></div><div>Option -G does not affect either of=
 these behaviors. I find it hard to believe that either Kernighan or Ritchi=
e would perpetrate such nonuniformity. Does anybody know whether it has any=
 historical justification?</div><div><br></div><div>Several other builtins =
share undefine&#39;s anomalous behavior for a missing argument list. Again,=
 special behavior entails extra documentation for each such builtin.=C2=A0<=
/div><div><br></div><div>I think the dnl diagnostic should be canned. I als=
o lament the nonuniform treatment of missing argument lists, and suggest it=
 be phased out: when undefine and its ilk are copied to output warn that th=
e bevior is scheduled to change.</div><div><br></div><div>Doug McIlroy</div=
></div>

--000000000000147aa20621caab73--