Re: Remaining non-blind macros

[Gary V. Vaughan]

Hi Eric!

Eric Blake wrote:
> I just looked at the list of blind macros (those that must be
> passed arguments to be recognized, such as define), and had
> a couple of questions.  Most of the builtins that are not blind
> have a reason; for example, dnl would be worthless if it were
> blind.  And I already recently changed indir and format to be
> blind.  However...
> 
> Any reason that shift is recognized even without arguments?

The only reason I can imagine is for compatibility with other
implementations.  The stable branch shouldn't change the status
quo, unless there is an actual (or at least potential) bug...
however, if you can find another (popular!) implementation of
M4 that has a blind shift macro, then our non-blind shift is
definitely buggy! :-)

> It is a common English word, but currently gets eaten when
> it appears alone.  Also, it is normally used as shift($@), and
> since it discards the first argument, it almost makes sense
> to require a first argument.  Would it cause anyone heartache
> if I changed shift to be blind?

Practically, I'd be very surprised.  If you want to make it
blind in HEAD, we can always change it back in compatibility
mode (--traditional) if existing code turns out to require
non-blind shift.

> What about m4wrap?  Because of the prefix, it is less likely
> to appear in ordinary text.  But it really makes no sense to
> wrap nothing; should I change it to be blind?

Same reasoning applies IMHO,

Cheers,
        Gary.
-- 
Gary V. Vaughan      ())_.  address@hidden,gnu.org}
Research Scientist   ( '/   http://blog.azazil.net
GNU Hacker           / )=   http://trac.azazil.net/projects/libtool
Technical Author   `(_~)_   http://sources.redhat.com/autobook

signature.asc
Description: OpenPGP digital signature