(j3.2006) COMPILER_OPTIONS and COMPILER_VERSION

[Van Snyder]

On Mon, 2008-09-22 at 06:48 -0700, Lionel, Steve wrote:
> 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.

If COMPILER_VERSION were specific, you could create a generic interface
of a different name with COMPILER_VERSION as one of the specifics.

If your processor (as opposed to your program) is the one providing
COMPILER_VERSION with an argument specifing a level of detail, it could
provide a specific COMPILER_VERSION with an optional argument, instead
of two specifics with hidden names and the generic name
COMPILER_VERSION.

Your program could provide a COMPILER_VERSION with an argument that
calls the COMPILER-VERSION from ISO_FORTRAN_ENV (after renaming it
during USE) and filters the result.  Of course, you'd want one of these
in every module, and as an internal procedure in every external
subprogram.  Yet another use for INCLUDE.

I don't understand why we prohibit a generic interface to have the same
name as one of its specific procedures.  The processor can clearly
figure out which is which in the case of intrinsic procedures.  Would
there be an insurmountable problem for program-defined generics?  I
don't see why: In procedure references, it's the generic name; in
pointer assignment or argument association, it's the specific name.

> 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.

The problem with generics is that you can't use them as actual arguments
or procedure pointer targets.  So the question whether procedures in
intrinsic modules ought to be specific or generic is not so obvious to
me.

This is the reason that "resolve generic to specific without invoking
procedure or evaluating arguments" was on my F2008 wishlist (item J3-021
in 05-145r3).

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

It's never too late to propose, but the proposal might be ignored.

> Steve Lionel
> Developer Products Division
> Intel Corporation
> Nashua, NH 
> 
> 
> 
> 
> _______________________________________________
> J3 mailing list
> J3 at j3-fortran.org
> http://j3-fortran.org/mailman/listinfo/j3