Re: AC quoting rules

[Bruce Korb]

> Bruce> Ah, the light dimly dawns.  We need M4 to support
> Bruce> pushquote/popquote.
> 
> >> changecom, changequote, changeword and changesyntax are only
> >> command line options which are moved into the M4 language....

> Paul> Aren't you two in violent agreement?  I think Bruce now
> Paul> understands why changequote doesn't work, and he is thinking of
> Paul> a new GNU M4 feature that should do what he wants.

> But of course, if you can *prove* when you pushlanguage that you never
> invoke the other language before the poplanguage, it is sane.  But
> then it means: you use no other Autoconf macro, and you don't use
> users' arguments (given they, too, belong to the [ ] world).

I think we all know how to program and we are, perhaps, picking
at nits just because our English is not as rigorous as our
programming.  I'm pretty sure I've been guilty of that during
this exchange.  (I do think the horse has likely died by now...)

But, just to be really sure of its death ;) ...

Adding push/pop quote to M4, to be useful in this context, would
also require that any macros that depended upon a particular
quoting phrases being current would need to push/pop it to what
it needed.  It would take some work.

Meanwhile, back to the "What to do?" issue that started this,
I have reached the conclusion that no solution works.
Akim favors burdening (my term) the user with worrying over
the balancing of square brackets.  I am in favor of an interface
whereby the user types in the script and program exactly the
way they want the text to be seen by /bin/sh and cc, respectively.
I believe that it is the responsibility of either autoconf or
a layer over autoconf to do whatever is required to push that
text through all the autoconf layers so that the final configure
script is doing exactly what was originally typed.  How that
is done is proving to be an "interesting" exercise.

The reason I now think no solution works is because of quoting.
Changequote works, but only if assured that it will not surround
any AC_* macros.  Global replacement of square brackets with
quadrigraphs has, it turns out, the same issue.  It's also ugly.
Scanning the source to ensure balance and replacing unbalanced
square brackets with quadrigraphs also has this Achilles heel,
but is less likely to be hit.  Additionally, it is pain to write
and I really do not see general application for it.  It seems
the only reasonable solution I can see is to provide several ways
to massage the text, one of which being to require the user to
fix the quoting issues.  At least I can put a big, bold caveat
next to the input text that links to a help page discussing the
various issues and ways around them.

Akim went on to say:
> If [there's anything] I'm proud of, it is [...] of having understood
> proper M4 programming.  I found no documentation at all about it, no
> doubt people were writing bad M4.  I consider I saved Autoconf thanks
> to that.
> 
> But some think I killed it.

Despite the fact that I detest M4 quoting, let me make it clear
that I do, in fact, appreciate the rigor you have brought to 
autoconf.  In fact, this rigor makes it possible to do an automated
or near-automated conversion of autoconf from an M4 based to
an AutoGen based set of macros. :-)  Doing so would completely
eliminate this discussion.  AutoGen macro markers cannot
be confused with source text, ever.  But not today.

> My point is, novices don't write macros,

My point is, novices don't write macros.  They don't because
the learning curve is much steeper than it needs to be.

> and slightly more advanced
> users don't have problems at all for writing macros by hand.

"at all" is too strong.  Witness the recent issue regarding argument
quoting with Glenn McGrath, someone who is clearly familiar with
autoconf.

> You will have to explain what is so hard about writing things like
> 
> # AC_FUNC_ERROR_AT_LINE
> # ---------------------
> AC_DEFUN([AC_FUNC_ERROR_AT_LINE],
> [AC_LIBSOURCES([error.h, error.c])dnl
> AC_CACHE_CHECK([for error_at_line], ac_cv_lib_error_at_line,
> [AC_LINK_IFELSE([AC_LANG_PROGRAM([],[error_at_line (0, 0, "", 0, "");])],
>                 [ac_cv_lib_error_at_line=yes],
>                 [ac_cv_lib_error_at_line=no])])
> if test $ac_cv_lib_error_at_line = no; then
>   AC_LIBOBJ(error)
> fi
> ])

That is very hard for the novice.  They just want to know, "Is
error_at_line() available?"  Understanding the above is very hard
compared with:

> group  = "ag";
> test   = {
>   name     = "error_at_line";
>   type     = "link";
>   check    = "error_at_line is available";
>   code     = <<- _END_OF_CODE_
>         #include <error.h>
>         main() {error_at_line (0, 0, "", 0, "");}
>         _END_OF_CODE_;
> 
>   action   = { no;
>     act-type = script;
>     act-text = <<- _END_OF_SCRIPT_
>         AC_LIBOBJ(error)
>         _END_OF_SCRIPT_; };
> };

(which I created by filling in the web page).  This is the result:

> AC_DEFUN([AG_LINK_ERROR_AT_LINE],[
>   AC_MSG_CHECKING([whether error_at_line is available])
>   AC_CACHE_VAL([ag_cv_link_error_at_line],[
>   AC_TRY_LINK(address@hidden:@include <error.h>
> main() {error_at_line (0, 0, "", 0, "");}],
>     [ag_cv_link_error_at_line=yes],[ag_cv_link_error_at_line=no]
>   ) # end of TRY_LINK]) # end of CACHE_VAL
>   AC_MSG_RESULT([${ag_cv_link_error_at_line}])
> 
>   if test "X${ag_cv_link_error_at_line}" = Xno
>   then
>     AC_LIBOBJ(error)
>   fi
> ]) # end of AC_DEFUN of AG_LINK_ERROR_AT_LINE

I think the autogen input lowers the bar considerably,
despite the ugliness of the ``#include'' directive.

-- 

Bruce Korb <first initial + last name at gnu dot org>
AG URL: http://autogen.sourceforge.net