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
