Re: justification for AC_LANG_ASSERT?

[Steven G. Johnson]

On Sat, 15 Nov 2003, Akim Demaille wrote:
> Nope, indeed, that's why it's too late to change the others.  But,
> IMHO, this interface is merely the unfortunate result of history,
> where Autoconf was not designed from scratch to support several
> languages. That's also why I would much better enforce the
> AC_LANG_PUSH/AC_LANG_COMPILER idiom than
> AC_PROG_WHAT'S_THE_NAME_OF_THE _COMPILER_AGAIN.

But it's even more confusing to use *both* idioms, with the AC_LANG_PUSH
idiom used for only *two* macros out of all autoconf.

> If you are sure that my mistake is an isolated case, and that noone, ever,
> will be lost in some obscure combination of FC vs. F77, then OK, we can
> revert.  But even in such a case (I'm the only loser), this is bad IMHO.

Akim, you're forgetting that there are downsides to the current choice,
too. I honestly think that far more people will be confused by an AC_PUSH
requirement that applies to only two macros in autoconf, compared to the
(I think, small) number of people who will be confused by those macros
behaving like the *rest* of autoconf's language-specific macros: macro
name indicates language.

> danger for C, C++ etc. I guess, but Fortran, hiding being a single
> name two different sets, is much more exposed to such problem.

Except it's not one name, it's two: FC and F77.

Unless the macro itself is polymorphic with the current language choice,
we're only arguing about syntax, not semantics.  The only difference
between my proposal (just call AC_FC_FREEFORM) and yours
(AC_LANG_PUSH(Fortran); AC_FC_FREEFORM; AC_LANG_POP(Fortran)) is how much
verbiage is required to convey the same semantic content.

Steven