Wow! Thanks for following up on this.
Eric Blake <ebb9@xxxxxxx> writes:
> Unlike the shell, we have no way to escape $ or { - right now, m4
> treats ${ as two literal characters. I think we are still okay,
> here - if the user wants these two characters literally, they do the
> same as they would to get a literal $1, by using appropriate nested
> quoting:
True, but there's a more general problem here: M4 doesn't let you
generate arbitrary output. In Autoconf we've worked around this
problem with quadrigraphs, but they're messy and slow because they
require a postpass with 'sed'. Is there some way that GNU m4 could
address this problem? E.g., m4_plainchar(nameofchar) or something lie
that. The idea is that the output of m4_plainchar is always treated
as a plain character; it never participates in any M4 syntax
afterwards, except as an uninterpreted string. That way, you can
output troublesome chars like ',' and '(' to your heart's content.
> Another thing to consider is whether { is the right character to use as
> the default for introducing a multi-character parameter.
Yes, I think so. ${ is used by both sh and make. To my mind the
long-term advantages of using consistent syntax far outweigh the
short-term disadvantages of breaking autom4te. We can fix autom4te
easily.
> Also, can we start to get a rough idea of how many existing m4 clients
> actually depend on $10 or greater, vs. how many use the sequence $< and
> expect it to pass through literally?
I don't know of any m4 clients depending on $10. Maybe some varargs
stuff? But they could be fixed, so long as there's an easy way to
decide between the old and new syntax. My vote would be to phase out
$10, so that we don't need to worry about POSIXLY_CORRECT here.
Bison does not use '${[0-9]'. Autoconf uses '${[0-9]' in six places,
all easily fixed:
lib/autoconf/programs.m4: ac_cv_prog_$1="$as_dir/$ac_word${1+' '}$[@]"
lib/autotest/general.m4: echo 'test "${ZSH_VERSION+set}" = set && alias -g '\''${1+"$[@]"}'\''='\''"$[@]"'\'''
lib/autotest/general.m4: '-v -d' "$at_debug_args" "$at_group" '${1+"$[@]"}'
lib/m4sugar/m4sh.m4: [#] Zsh 3.x and 4.x performs word splitting on ${1+"$[@]"}, which
lib/m4sugar/m4sh.m4: alias -g '${1+"$[@]"}'='"$[@]"'
lib/m4sugar/m4sh.m4: exec "$CONFIG_SHELL" "$as_myself" ${1+"$[@]"}])
The use of ${ followed by a nondigit is more common, but presumably
that's not an issue here. If it were a problem, the problem would be
shared by $<, since Bison uses $<foo>.
Autoconf and Bison do not use '$<[0-9]'.
> XCU ERN 119 is another one of these - the sentiment today was that
> supporting a range operator in translit is contrary to POSIX 2001, but
> that the next revision is an appropriate time to take my suggestion
Yes, that's a fairly common reaction. If they plan to take the
suggestions it's OK to act on the suggestions now, and remove the
dependency on POSIXLY_CORRECT for define and translit.
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
http://lists.gnu.org/mailman/listinfo/autoconf
