Re: justification for AC_LANG_ASSERT?

[Akim Demaille]

 > Akim Demaille wrote:
 >> Yes, but again, some dummies ---such as me---, will really believe FC
 >> is polymorphic wrt the Fortran flavor.

 > Akim, it's not that you're "dumb," but your use of the macros in the
 > test program is *extremely atypical*.  You weren't actually *using*
 > the macros for anything, you just wanted to call them in order to test
 > them. There was no reason for you to even think very closely about
 > what the macro is for---you're not doing any Fortran programming,
 > after all (lucky you). 

:)

 > On the other hand, when a user wants to call, say, AC_FC_FREEFORM,
 > it will be because she actually has free-form Fortran 90 source
 > code or similar, and is therefore not using legacy Fortran 77.

Right, you made a point.


 > I think it's a mistake to make judgements about usability from such an
 > artificial circumstance.

OK.


 >> Not if you consider that this is only the beginning.  We have to
 >> start somewhere, and the fact that there are two flavors of
 >> Fortran emphasizes that need.

 > Akim, you've chosen a bad example to illustrate the "need": the two
 > macros you chose to require AC_PUSH/POP are meaningful *only* for
 > "modern" Fortran, not the legacy Fortran 77 flavor.

Maybe the example is bad, granted, but it is still a part of an
evolution I believe we should perform in Autoconf.

 > The use for AC_PUSH/POP should be for macros, like AC_LANG_COMPILER,
 > that are polymorphic over the current language.  In this case, the
 > PUSH/POP actually adds some semantic content.

I'm not that sure about.  Plus you are engaging Autoconf for the
future, and I don't.  Imagine a future into which there is yet another
version of Fortran, that requires a polymorphic AC_FC_FOOBAR (with
foobar being for instance freeform), your scheme is dead, mine is not.

Actually, don't even think about this future, just think about my
reluctance to the current scheme followed to implement Fortran.  From
the beginning I was again this second set of macros, I was willing to
push towards polymorphic macros for Fortran flavors.  There was a
problem, granted, with F77 as a name for "generic" Fortran.
Nevertheless the point remains valid.

When I read things such as:

   # AC_PROG_F77_C_O
   # ---------------
   AC_DEFUN([AC_PROG_F77_C_O],
   [AC_REQUIRE([AC_PROG_F77])dnl
   AC_LANG_PUSH(Fortran 77)dnl
   _AC_PROG_FC_C_O
   AC_LANG_POP(Fortran 77)dnl
   ])# AC_PROG_F77_C_O
   
   
   # AC_PROG_FC_C_O
   # ---------------
   AC_DEFUN([AC_PROG_FC_C_O],
   [AC_REQUIRE([AC_PROG_FC])dnl
   AC_LANG_PUSH(Fortran)dnl
   _AC_PROG_FC_C_O
   AC_LANG_POP(Fortran)dnl
   ])# AC_PROG_FC_C_O
   
I find another set of arguments in favor of my scheme: the code itself
pushes toward polymorphism, there's just a nutshell wrapping it away
from the user.

I think this is wrong.


 > This does not apply for macros that are language-specific, and by
 > definition any macro that uses AC_LANG_ASSERT is language-specific.

You still have not addressed what does matter to me: because the
language are handled as a side effect in Autoconf, it is wrong to have
macros escape this and not emphasize the importance of having language
dedicated paragraphs in configure.ac.

It is just a matter of Good Style.