Re: enhancement suggestions

[Akim Demaille]

>>> "Stepan" == Stepan Kasal <address@hidden> writes:

 > Hi Akim and Gary,

Hi!

 > On Thu, Feb 10, 2005 at 01:55:16PM +0100, Akim Demaille wrote:
 >> >>> "Stepan" == Stepan Kasal <address@hidden> writes:
 >> > +  + We need a way to ask for one level of expansion; this is somewhat
 >> > +    similar, but not identical, to `defn'.  For example:
 >> > +       expandonce(`macro(a, b, c)')

 >> I'm not sure I agree with the "once".  You just apply the regular
 >> evaluation rules, and return the result quoted.  But if foo is defined
 >> to bar, and bar to baz, then eval([foo]) should definitely return [baz].

 > I believe this can be implemented as

 >      define([m4_quote], [[$1]])

 > the parameter is fully evaluated and then quoted.  Unless the expansion
 > contains an unmatched quote, everything works.

That's the whole point!  m4_quote is a naive version of something that
should be provided by m4.  The big difference bw m4_quote and the eval
we lack is that you pass *unquoted* arguments to m4_quote: that's
*very* dangerous.  To make it clear:

       m4_quote(foo)

corresponds to

       eval([foo])

This level of quotation makes it safer.

 > What we need is exactly the ``once'' feature.

I don't think so: it fits nowhere in the semantics of M4.  It will
introduce a difference between chains of macros and simple-depth
definition, which, honestly, I fail to see meaningful within M4.
Exceptions in semantics are *bad*.  M4 is quite clean but suffers a
few defects.  Let's not introduce exceptions.

 > After an irc discussion with Gary, his proposal has landed as `qindir' to
 > the TODO file in the CVS head.  Let me cite it:

 >   + Implement qindir.  Like indir, except that the result of the macro call
 >     is not expanded.  Because the input stack might contain a file or a
 >     string, it is probably best achieved by making note that the TOS input
 >     should be copied rather than rescanned.

 >       $ echo "a'b" > f
 >       $ m4
 >       define(a,z)dnl
 >       include(f)dnl
 >       z'b
 >       indir(`include', f)dnl
 >       z'b
 >       qindir(`include', f)dnl
 >       a'b
 >       define(b,NONO)dnl
 >       patsubst(qindir(`include', f), b, x)
 >       z'x

I don't want that: you ask me to introduce a macro when I was to run
some piece of arbitrary program, including

     eval([foo bar])

where foo and bar are both macros.  I don't want to introduce a
foo_bar to do that.

qindir can arguably solve the issue of the broken builtins, but it
does not address eval itself.



The problem is that some macros are *broken* because they do not quote
their result.  Why make correct programs harder to write because you
have to invoke qindir?


 >> As in qregexp, qinclude, qifelse and so on?  [...]

It doesn't make sense for ifelse, but the other twos, yep.

 >> > While you're at it, the new regexp
 >> > builtins should drop BRE dead, and use ERE too.

 > Well, as it doesn't look as if we were adding an alternate set of
 > builtins,

Too bad.

 > I believe we could take this as a proposal to implement `eregexp'
 > and `epatsubst'.

Definitely.  And these macros quote their result :)