Re: Wondering why m4 ignored namespace concept

[Eric Blake]

On 07/14/2014 11:45 PM, Daniel Goldman wrote:
> 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.

Alas, history is not on our side. M4 was defined in 1977,
http://dl.acm.org/citation.cfm?doid=367177.367223, which lacked wrap and
exit builtins.  But as other people started using the language, those
builtins were soon added by third parties.  By the time the GNU project
decided to add an implementation of m4, in 1990, we were already stuck
with the names m4exit and m4wrap in order to match existing practice of
other implementations; and this practice has actually been codified into
POSIX:
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/m4.html

> 
> 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.

You _do_ realize that you are free to rename macros into a consistent
namespace, right?  For example, the very first thing autoconf does when
initializing m4, right after using changequote to use [] instead of `',
is to rename all the builtin macros into a single namespace.  Thus,
autoconf has 'm4_define' and 'm4_exit', not 'm4_m4exit'.  It's as simple as:

changequote([,])
define([m4_define], defn([define]))
m4_define([m4_defn], defn([defn]))
m4_define([m4_exit], m4_defn([m4exit]))
m4_define([m4_undefine], m4_defn([undefine]))
m4_undefine([define])
m4_undefine([defn])
m4_undefine([m4exit])
m4_undefine([undefine])

and so on.

> 
> "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) :)

No, it's not.  It's the only way we can change this.

> 2) Make all builtins like m4_define, m4_include, etc.

Yes, you are free to do this yourself.  Autoconf does.

> 3) Get rid of -P option (not needed).

We can't drop it now; people have already come to rely on our extension,
even though it is not defined by POSIX.

> 4) If new builtins added, use m4_exit, m4_wrap, etc.

GNU M4 added several builtins that were not existing practice at the
time, such as 'regex'.  If we had a time machine, then yes, any new
macros added at that time could have been namespaced, keeping only the
original portable names as bare.  But as we've already argued, it's so
trivially easy to rename a macro into whatever namespace you want that
it isn't worth the extra typing of new builtin names, and instead leave
it up to the end user to do it.

At this point in time, we are unlikely to add any new builtins by
default.  One of the ideas for an eventual m4 2.0 was to allow modules,
where you could add new builtins by loading a module - but the point
remains that those builtins are not loaded by default, but by explicit
action; and therefore, there is no risk of breaking existing behavior if
you do not load the new module, and conversely, anyone loading a module
still has control to rename the macros into a namespace.

> 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.

Here, __line__ was a GNU extension copying after the preprocessor; but
consistency argues that -P always adding 'm4_' instead of completely
renaming the macro is easier to do.  But again, you are free to redefine
it to whatever name you want.

> 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?

Historical compatibility.

> 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.

Because GNU m4 was just copying what others had already done, and then
adding some more builtins at the time.

> 
> 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.

Unlikely to happen.  But thanks for your thoughtful analysis.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature