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
