Wondering why m4 ignored namespace concept

[Daniel Goldman]

When I started using m4, m4exit and m4wrap seemed pretty geeky,
inconsistently named. Since I always use -P option, these get converted
to m4_m4exit and m4_m4wrap. Seems pretty kludgy. But I make do. It seems
that the odd m4exit and m4wrap names were to protect legacy input files
that have the word "exit" or "wrap" in them, as apparently these were
builtins added later. Just a guess. If my guess is wrong, the odd names
are even odder.

I adapted. I'm used to geeky things, it comes with the territory. m4 has
a lot of good points, so I put up with the bad. I always use -P as a
workaround, so I am not really "suffering". But the naming system seems
bad looking and unfriendly. I would say the language is "suffering". If
anyone wonders why m4 is not more popular, here is one reason. I speak
from direct experience, as a new user.

"Two wrongs do not make a right." - *** Wrong #2. Starting backwards, I
would suggest wrong #2 was to use names like m4exit and m4wrap. But I
guess a necessary evil at that point. *** Wrong #1. I would suggest it
was a fundamental wrong to use "define", "include", etc. It seems
obvious (to me) these should have ALWAYS been m4_define, etc. There is
this concept of "namespaces" to prevent naming conflicts. I would hope
this might have crossed someone's mind way back when. No normal usage is
going to use "m4_define" in an input file other than as a builtin.
Obviously, various builtins can easily be used all over the place.

So my suggestion is:

1) Go back in a time machine. (That's a joke) :)
2) Make all builtins like m4_define, m4_include, etc.
3) Get rid of -P option (not needed).
4) If new builtins added, use m4_exit, m4_wrap, etc.

Besides simplifying things, preventing conflicts, and looking a lot
better, another advantage is to improve searching and maintenance. The
user can easily find all instances of m4_define, "\<m4_[A-Za-z_0-9]*\>"
etc., in input files, on this discussion group, etc. I find it useful.

My suggestion would also get rid of the geekiness with __line__ ->
m4___line__ where I think m4_line would have been a lot better.

Maybe _m4_ prefix might be even better, but I think m4_ is probably
unique enough.

Even the m4 manual acknowledges the existing naming convention is a
problem, in the following somewhat misleading text: "An innovation of
the m4 language, compared to some of its predecessors (like Strachey’s
GPM, for example), is the ability to recognize macro calls without
resorting to any special, prefixed invocation character. While generally
useful, this feature might sometimes be the source of spurious, unwanted
macro calls. So, GNU m4 offers several mechanisms or techniques for
inhibiting the recognition of names as macro calls.".

Misleading? Well, I would hardly call the naming convention an
"innovation". That demotes "innovation" to such as low level as to be
meaningless. And is this "innovation" really "generally useful", more
useful than the alternative? Again, I am just referring to builtin
names, and of course in saying "spurious, unwanted macro calls" the
manual is referring to builtins. The user can name composite macros
whatever they please. If the user has any sense, they will pick a unique
name that will not otherwise occur. If they don't, it's their own darn
fault. I use m4_ prefix for all composite macros I make. It's just
common sense and maintains the ease of searching.

The manual goes on with some weird gyrations suggested for preventing
"spurious, unwanted macros calls" of "divert". Give me a break. I am NOT
going to mark up an input file with special quote delimiters. That is
ridiculous, so incredibly awful. And then the manual has the equally
weird suggestion to "redefine problematic macros to a name less likely
to cause conflicts". :( Please, don't put the burden on the user. My
whole point is that the names "cause conflicts", so the manual at least
admits (without really wanting to admit) the problem.

Related to preventing "spurious, unwanted macro calls" are the
restriction that parentheses have to directly follow macro names, and
GNU extensions to ignore (not expand) many macros not followed by
parentheses. Admittedly this helps, but I would suggest "three wrongs do
not make a right". Or maybe it is four wrongs at this point! :) If the
original policy had been to use a separate namespace for the builtins,
none of these restrictions and special extensions would have been needed.

Here (finally!) is my question: Does anyone know why builtins were not
required to start with m4_ prefix? Basically, what is the advantage of
not using a namespace?

My guess, just a hypothesis based on what I've seen, is that there is no
advantage, that when m4 was originally written, nobody dreamed it would
be used all that much, or had all that much time and energy to devote,
and it worked well enough for the initial limited usage, so there were
some design mistakes, including this one, and the mistakes got frozen in
place. Please tell me I'm wrong, that there was some grand purpose to
ignoring the namespace concept.

It seems m4 development is kind of stuck. And even if it were not, there
are of course potential downsides to changing anything, as countless
scripts depend on m4, and this is not a minor change. On the other hand,
m4 already has an extremely obscure --warn-macro-sequence option, and
nobody seems worried about that. So maybe there could be an
--old-naming-system option to run m4 in the current geeky mode.

But I'm not really expecting anything to happen. I've already gotten
that message pretty clearly! I'm not blaming anyone, it's just the way
things are. Perhaps hardly anybody cares, or is even listening. Or
perhaps users are satisfied with the current state of affairs, perhaps
some even revel in the complexity and obscurity. Anyway, the purpose of
this post, if anyone still reading, :) is to:

1) Find out the reasoning (if any) why the original decision was made
not to always preface builtins with m4_ prefix.

2) Point out something that seems (to me) obviously inferior, but which
nobody else seems to have noted.

3) If my comments are valid, suggest that in some "better m4 in distant
future", m4 always use m4_ prefix for builtins.

Thanks,
Daniel