Re: justification for AC_LANG_ASSERT?

[Steven G. Johnson]

On Thu, 20 Nov 2003, Akim Demaille wrote:
> Right.  The day we have OOAutoconf, then we can write
> 
> $lang.AC_COMPILER_CHECK
> $lang.AC_CHECK_FUNC(fnmatch)

But <lang>.AC_COMPILER_CHECK is just an alternate spelling of
AC_<LANG>_COMPILER_CHECK or AC_PROG_<LANG>.   You are proposing and
criticizing the same thing!

> but as of today, this is addressed via a hidden global.  Pretending it
> is not there seems even worse to me.

But it *isn't* addressed via a hidden global for AC_<LANG>_FOO macros;
these have exactly the semantics of <lang>.AC_FOO that you propose above.

AC_CHECK_FUNC et al. are a different matter.

>    # AC_PROG_FC_C_O
>    # ---------------
>    AC_DEFUN([AC_PROG_FC_C_O],
>    [....
>     AC_LANG_COMPILER_REQUIRE
>    ])# AC_PROG_FC_C_O
> (this is what was _AC_PROG_FC_C_O).

So, instead of having AC_PROG_FC_C_O (current), you are
recommending:

AC_LANG_PUSH(Fortran)
AC_PROG_FC_C_O
AC_LANG_POP(Fortran)

How is this better?  This is just a different (and more verbose) spelling.

Rather, I would suggest the following:

1) If you like the AC_PUSH style, encourage users to use it with the
generic AC_LANG_COMPILER, possibly writing new language-dispatched macros
like AC_LANG_COMPILER_C_O for generic-enough features.  Do this for *all*
languages; doing it for just a few macros of one language is worse than
for none at all.

2) Keep the current AC_PROG_<LANG> style macros for people still using the
"old style".

3) For macros that truly are specific to a particular language, like
AC_FC_FREEFORM, keep them the way they are.  This has the right semantics,
since AC_<LANG>_FOO is an alternate spelling of <LANG>.AC_FOO, and the
language-specific AC_<LANG>_FOO is a natural syntactic parallel to the
language-generic AC_LANG_FOO.

4) Ditch AC_LANG_ASSERT(<LANG>), because it is redunant for a
language-specific AC_<LANG>_FOO macro (an inapplicable to generic
AC_LANG_FOO macros).

> The mess wrt variables (FC vs. F77 etc.) needs special treatment,
> agreed.  But, for a start, do we really have projects cumulating both
> flavors?

Yes.  I do it myself, and other people came out about this every time we
debated it on the mailing list.  There are 30 years of legacy F77 code out
there that people aren't willing to touch, and bringing it up-to-date with
the latest standards is a major effort.

> And if so, how come we didn't care about those mixing Fortran 95 vs.
> say Fortran 2000?

Because Fortran 95 and Fortran 2000 are basically compatible with one
another (and are close in time so that the people writing the codes didn't
die decades ago), whereas F77 is essentially a different language.  It
makes sense to treat it, *going forward*, like C and C++, where we don't
have different macros for different versions of the language.  We just
expect people writing C code to maintain their code so that it is at least
compatible with the latest standard (not hard to do), and to test
feature-by-feature for new features if necessary.

Steven