Re: Wondering why m4 ignored namespace concept

[Eric Blake]

On 07/17/2014 03:38 AM, Daniel Goldman wrote:

>> 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'm not sure what the acm citation is, or how it relates. It says it was
> published in 1960 (?). I'm not going to pay $15 :( to find out more, as
> the link requires. The POSIX text says 2001, I'm not sure how that
> relates to the GNU development. I wouldn't know if GNU m4 was already
> "stuck with the names", or not. I'm not saying you are wrong, I'm not an
> "m4 historian", but the links you cite don't seem to support GNU m4
> being "stuck".

Bah. There are multiple links at
https://www.gnu.org/software/m4/manual/m4.html#History; I first picked
the ACM link from 1960, but as you discovered, it is behind a paywall,
and not actually describing m4.  Then I checked a later link from 1977:
http://wolfram.schneider.org/bsd/7thEdManVol2/m4/m4.pdf, but forgot to
update the link in my email compose window.

> 
> Anyway, I never raised the issue of whether GNU m4 was "stuck with the
> names", and don't really care at this point, as my post is really about
> what "should be". To help figure that out, my post asked why the
> decision was made when m4 was "originally developed", I did not ask
> about GNU m4. If some advantage to the "no namespace" decision, that
> would help me to know. If there was not, then I'm afraid this is another
> example where the GNU m4 manual exaggerates / makes a mis-statement. It
> says the naming convention is an "innovation" (!) and "generally useful"
> (!), implicitly in comparison with always using m4_ prefix for builtins.
> I don't buy that.

State of the art in the 70s was different than it is today.  Raphael
gave some good answers: memory constraints, smaller programs, less
practice with namespace collisions.

If you think the manual makes a mis-statement, please propose a patch.
The M4 language is definitely NOT innovative today, but it WAS
innovative at the time it was first created.

> 
> And again, my post is not to blame anyone, all those old developers from
> decades ago are perhaps dead anyway at this point (but it would great if
> some of them were lurking on this group, and could spell out why the
> original decision was made).

I seriously doubt that any of the original M4 authors read this list, as
GNU M4 was created as a clone in 1990.

> My post is to think about what the right
> method is, even if that can't be changed today. Nothing lasts forever.
> It would be naive to bet that m4 will necessarily be around in 10 years
> (or maybe 25, you get the point).

If you are writing a language from scratch, great.  Use the current best
practices.  But if you are using a language that has a 40 year history,
don't break it.  Whether or not it will be around in 25 years is hard to
predict, but since it has lasted nearly 40 years and been standardized
by POSIX, I seriously doubt it will ever disappear.  There may not be
much new usage of it, but one thing you learn in computer science is
that supporting old formats is essential for continuity, even when new
formats are introduced into the mix.


> If you don't see the kludginess of renaming the default names, I don't
> know what to say. What would you think if you saw C code where someone
> renamed a bunch of C functions?

Gnulib does just that, to work around brokenness in various vendor's
libc.  But by isolating the renames to a few key include files, no one
else in the code base has to care about the games gnulib had to play to
get to that point.

> Gawd!!! The desire to rename various
> builtin macros to begin with m4_ prefix makes my point the language
> would have been better designed to name them that way in the first
> place. That's all I'm saying. You could just say "you're right" and move
> on. I don't see the point in trying to defend the indefensible. :)

Sure - you're right.  Hindsight is 20/20 - if we were designing the
language today, it would be a lot different, and would probably be
namespaced consistently off the bat.  But we aren't designing it today.
 So who cares?  Philosophizing about what could have been only wastes
time.  It's not like you are posting patches to change all of this

> 
> BTW, why do you say "was to allow modules" (not "is")? Is modules idea
> thrown out? Is there a list of other ideas for "eventual m4 2.0"?

The problem, as you may have noticed, is lack of developers with enough
free time to push m4 2.0 to completion.  Unless that changes, m4 2.0 is
stalled as a set of half-baked patches that need a lot of TLC.


> 
> I understand why __line__ was named such, and it's all understandable
> given the lack of a namespace. It just seems obviously kludgy to me, and
> probably to many others.

Kludgy is in the eye of the beholder.  But it works.  So it's not worth
breaking.

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

signature.asc
Description: OpenPGP digital signature