Re: justification for AC_LANG_ASSERT?

[Steven G. Johnson]

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.

Honestly, I'm not convinced that AC_LANG_PUSH/AC_COMPILER is a better 
idiom than having the language specified per-macro via the macro name. 
In the AC_LANG_PUSH scenario, the meaning of AC_COMPILER etcetera 
depends upon a global state that is set elsewhere, i.e. is invisible at 
the time the AC_COMPILER macro is called.  The history of computer 
science suggests that having the meaning of a function change 
drastically as a side-effect of an earlier function call is not a recipe 
for clarity.

> This scheme already shows its limitations with Fortran.  If we had followed
> only the AC_LANG_* scheme, there would not have been such confusion.

Remember, the main trick for Fortran was not a question of specifying 
the language (which could have been done already just by passing the a 
different list of compilers to AC_PROG_F77), but the fact that you 
really need two sets of output variables so that F77 and modern Fortran 
can be used simultaneously in the same Makefile.

(And, as I said in another message, for new macros like AC_FC_FREEFORM 
that correspond to new features of modern Fortran only, the polymorphism 
implied by AC_LANG_PUSH is not useful.)

Steven