(j3.2006) COMPILER_OPTIONS and COMPILER_VERSION

[Lionel, Steve]

Bob Corbett wrote:

> >
> > Given that they have no arguments, I don't see how they could be
> > generic.
> 
> I think you make a good case for explicitly stating whether they
> have specific or generic interfaces.  Consider the generic
> intrinsic function COMMAND_ARGUMENT_COUNT.

Ok, I now see why the distinction matters - this had not occurred to me
last week.  If the interface is generic, it can be extended, with
required arguments used to distinguish the signatures.  So one might for
example have a variant of COMPILER_VERSION with an argument specifying
some level of version information.  If COMPILER_VERSION was not
specified as generic, you could not extend it.

The only place that calls COMMAND_ARGUMENT_COUNT generic is in the title
of section 13.5, but that's enough.  I now agree that the specification
of intrinsic module procedures should specify whether or not they are
generic.  For example, 13.8.2.1 could be amended to say "The processor
shall provide the named constants, derived type, and *generic*
procedures described in subclause 13.8.2."  I note that 15.2.3.1 for
ISO_C_BINDING says "procedure names are generic and not specific" and
14.11.1 for the IEEE Exceptions modules makes a similar claim.  This was
evidently overlooked for the addition of procedures to ISO_FORTRAN_ENV.

Is it too late to propose an edit for F2008?  I'm not sure what the
process is at this stage.

Steve Lionel
Developer Products Division
Intel Corporation
Nashua, NH