Re: AC quoting rules

[Bruce Korb]

Paul Eggert wrote:
> > > * They learn the [ugly] quoting rules.
> It is so ugly and hard-to-read that it is hard to maintain.
> That makes it "wrong"...

OK.  We agree.  :-)

> ... You can use minimal quoting, as follows:
> 
>   1.  Replace only _unmatched_ [s and ]s with quadigraphs.

Which means writing a special purpose C routine that has no
purpose outside of the "special" needs of autoconf.

>   2.  Surround the resulting strings with [ and ].
>   3.  If you don't want nested evaluation for a macro argument,
>       surround it with another [ and ].

The doc said:
> Quotation and Nested Macros
> ---------------------------
> 
>    The examples below use the following macros:
> 
>      define([car], [$1])
>      define([active], [ACT, IVE])
>      define([array], [int tab[10]])
> 
>    Each additional embedded macro call introduces other possible
> interesting quotations:
> 
>      car(active)
>      =>ACT
>      car([active])
>      =>ACT, IVE
>      car([[active]])
>      =>active

Q:  What happens to ``car([int array[5]])'' ?
    To  ``car([[int array[5]]])'' ?

This is severe uglitude.  Mostly because it is fuzzy.
In any case, it leaves me wondering
if, in general, all arguments to all macros should be double
quoted; or is it particular arguments to particular macros
and how would one tell the difference?  Remember, too, that it
is not a human typist inserting text into these macros.  It is
a program inserting text strings that was given to it....

> This approach is much easier to read than the
> "let's quadrigraph every bracket" approach.

Actually, I did this:
> (define (protect-text t)
>     (string-substitute t
>         '("["     "]"     "$"     "#"     )
>         '("@<:@"  "@:>@"  "@S|@"  "@%:@"  ))  )

fundamentally assuring that it was not possible for there to be
any confusion between autoconf-interesting characters and
stuff I wanted passed through to the output shell script.

> > Well, that it should be so hard ...
> > bespeaks of some severe design issues.
> 
> Quoting is _always_ a severe design issue.  In every language that has
> arbitrary strings.  One cannot escape it.

I am aware of that.  It is why I made the choices I did in AutoGen.
Specifically, the author of each template file (read:  macro or
macro collection) chooses the start/end quote markers that are
guaranteed unique within that template.  They have no interaction
with quoting used in any other template file, even those included
by their template file.  There is also no interaction between these
quote markers and input definition strings (read:  macro arguments).
Ambiguity is far more evil than clutter, though clutter is very
bad, too.

> A lot of it is what you're used to.  The quoting rules of m4 are not
> that bad, once you get used to them.  They're simpler than the quoting
> rules of C, for example.  (_Much_ simpler than those of Perl.  :-)

You're not even mentioning the shell's eight different rules!
FYA(musement):
  1.  'xxx'
  2.  "xxx"
  3.  `xxx`
  4.  "`xxx`"
  5.  cat <<EOF
  6.  cat <<'EOF'
  7.  cat <<- EOF
  8.  cat <<- 'EOF'  (did I miss any, other than ksh's $()? ;)

The M4 quoting "rules" are actually the same as AutoGen, _except_
that there cannot be abmiguity in AutoGen, and the quoting used in
one file has no effect in any other file (for AutoGen).

> There is no problem with doing it at the top level.  But there is a
> problem with using changed quotes within the argument of a macro.
> That is because the changequote has global effect even though it is
> executed on behalf of (say) a single string at one evaluation level.
> If you have nested macro calls, the callee does not know that the
> caller invoked changequote, and thus the callee will use the wrong
> quoting rules.

Ah, the light dimly dawns.  We need M4 to support pushquote/popquote.
It seems that would solve the issue.

-- 

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