experchange > fortran

jfh (11-22-19, 01:20 AM)
The f2018 standard 3.89 says an inquiry function is an intrinsic function, or function in an intrinsic module, whose result depends on the properties of one
or more of its arguments instead of their values.

I think that needs rewriting because not every inquiry function has at least one argument. Counter-examples include command_argument_count(), compiler_options(), and ieee_support_nan(), which are respectively intrinsic, in iso_fortran_env, and in ieee_arithmetic.
gah4 (11-22-19, 01:34 AM)
On Thursday, November 21, 2019 at 3:20:21 PM UTC-8, jfh wrote:
> The f2018 standard 3.89 says an inquiry function is an intrinsic
> function, or function in an intrinsic module, whose result depends
> on the properties of one
> or more of its arguments instead of their values.


> I think that needs rewriting because not every inquiry function
> has at least one argument. Counter-examples include
> command_argument_count(), compiler_options(), and ieee_support_nan(),
> which are respectively intrinsic, in iso_fortran_env,
> and in ieee_arithmetic.


There are many inquiry functions that return some property of
the argument unrelated to its value, or even having a value.

KIND()

will give the KIND of a variable (or, I believe, expression)
even if the variable doesn't have a value, such as an unallocated
allocatable. For those, there has to be at least one argument.

Now that you mention it, I am not so sure what the standard
says about inquiry functions.

Recent discussion about MERGE, and the possibility for a function
like MERGE that didn't unnecessarily evaluate its arguments had me
looking into the different function types. (MERGE is elementary.)

None of the existing function types allow for a MERGE that
doesn't evaluate an argument when the value isn't needed.
(MERGE, and the optimization rules in general, allow expressions
not to be completely evaluated, but don't require them not to be.)
FortranFan (11-22-19, 01:37 AM)
On Thursday, November 21, 2019 at 6:20:21 PM UTC-5, jfh wrote:
> The f2018 standard 3.89 says an inquiry function is an intrinsic function, or function in an intrinsic module, whose result depends on the properties of one
> or more of its arguments instead of their values.
> I think that needs rewriting because not every inquiry function has at least one argument. Counter-examples include command_argument_count(), compiler_options(), and ieee_support_nan(), which are respectively intrinsic, iniso_fortran_env, and in ieee_arithmetic.


Re: OP's comment, "I think that needs rewriting" - I doubt the WG5 editor of the standard will agree:

1) command_argument_count is classified as transformational (T) and not as an inquiry function, and

2) with the other two, the standard states in 16.10 Standard intrinsic modules under Note 1, "The types and procedures defined in standard intrinsic modules are not themselves intrinsic."

The first one
FortranFan (11-22-19, 01:38 AM)
On Thursday, November 21, 2019 at 6:20:21 PM UTC-5, jfh wrote:
> The f2018 standard 3.89 says an inquiry function is an intrinsic function, or function in an intrinsic module, whose result depends on the properties of one
> or more of its arguments instead of their values.
> I think that needs rewriting because not every inquiry function has at least one argument. Counter-examples include command_argument_count(), compiler_options(), and ieee_support_nan(), which are respectively intrinsic, iniso_fortran_env, and in ieee_arithmetic.


Re: OP's comment, "I think that needs rewriting" - I doubt the WG5 editor of the standard will agree:

1) command_argument_count is classified as transformational (T) and not as an inquiry function, and

2) with the other two, the standard states in 16.10 Standard intrinsic modules under Note 1, "The types and procedures defined in standard intrinsic modules are not themselves intrinsic."
jfh (11-22-19, 02:54 AM)
On Friday, November 22, 2019 at 12:38:10 PM UTC+13, FortranFan wrote:
> On Thursday, November 21, 2019 at 6:20:21 PM UTC-5, jfh wrote:
> Re: OP's comment, "I think that needs rewriting" - I doubt the WG5 editorof the standard will agree:
> 1) command_argument_count is classified as transformational (T) and not as an inquiry function, and
> 2) with the other two, the standard states in 16.10 Standard intrinsic modules under Note 1, "The types and procedures defined in standard intrinsicmodules are not themselves intrinsic."


Apologies. I was wrong on command_argument_count (and also on compiler_options) because they are not inquiry functions. However F2018 3.89 allows non-intrinsic inquiry functions if they are in intrinsic modules, and ieee_support_nan is one of the 10 inquiry functions in the intrinsic module ieee_arithmetic that can be invoked with no arguments (F2018 Table 17.2 and 17.11.55). My objection to the present wording of 3.89, which assumes at least oneargument, still stands.
steve kargl (11-22-19, 04:37 AM)
FortranFan wrote:

> On Thursday, November 21, 2019 at 6:20:21 PM UTC-5, jfh wrote:
> Re: OP's comment, "I think that needs rewriting" - I doubt the WG5 editor of the standard will agree:
> 1) command_argument_count is classified as transformational (T) and not as an inquiry function, and
> 2) with the other two, the standard states in 16.10 Standard intrinsic modules under Note 1, "The types and procedures defined in standard intrinsic modules are not themselves intrinsic."


IEEE_SUPPORT_DATATYPE (), IEEE_SUPPORT_DENORMAL (), IEEE_SUPPORT_DIVIDE (), etc
are inquiry functions from the intrinsic IEEE_ARITHMETIC modules. These can be called
with no argument. If what John states about 3.89 is true, then J3 should fix the
Standard as the result does not depend on the properties on one or more arguments.
steve kargl (11-22-19, 08:52 PM)
jfh wrote:

> The f2018 standard 3.89 says an inquiry function is an intrinsic function, or function in an intrinsic module, whose result depends on the properties of one
> or more of its arguments instead of their values.
> I think that needs rewriting because not every inquiry function has at least one argument. Counter-examples include command_argument_count(), compiler_options(), and ieee_support_nan(), which are respectively intrinsic, in iso_fortran_env, and in ieee_arithmetic.


John, I sent the J3 mailing list the following email:

The document I have is 18-007r1.pdf.

On page 3,

3 Terms and definitions

For the purposes of this document, the following terms and
definitions apply.

On page 12,

3.89
inquiry function
intrinsic function, or function in an intrinsic module, whose result
depends on the properties of one or more of its arguments instead of
their values

John Harper on comp.lang.fortran has pointed out that the above
definition needs to be updated/modified. Consider,

USE IEEE_ARITHMETIC
PRINT *, IEEE_SUPPORT_DENORMAL()
END

IEEE_SUPPORT_DENORMAL is a "function in an intrinsic module" and
17.11.49 (page 460) indicates "Class. Inquiry function". In the
above valid Fortran code, the inquiry function has no arguments,
so does it have a result?
Steve Lionel (11-22-19, 11:32 PM)
On 11/21/2019 9:37 PM, steve kargl wrote:
> IEEE_SUPPORT_DATATYPE (), IEEE_SUPPORT_DENORMAL (), IEEE_SUPPORT_DIVIDE (), etc
> are inquiry functions from the intrinsic IEEE_ARITHMETIC modules. These can be called
> with no argument. If what John states about 3.89 is true, then J3 should fix the
> Standard as the result does not depend on the properties on one or more arguments.


I think this would make a good interpretation request.
steve kargl (11-23-19, 12:10 AM)
Steve Lionel wrote:

> On 11/21/2019 9:37 PM, steve kargl wrote:
>> IEEE_SUPPORT_DATATYPE (), IEEE_SUPPORT_DENORMAL (), IEEE_SUPPORT_DIVIDE (), etc
>> are inquiry functions from the intrinsic IEEE_ARITHMETIC modules. These can be called
>> with no argument. If what John states about 3.89 is true, then J3 should fix the
>> Standard as the result does not depend on the properties on one or more arguments.

> I think this would make a good interpretation request.


Hi Steve,

I've opened a discussion on the J3 mailing list. Hopefully, a full borne
interpretation request isn't needed.
jfh (11-28-19, 01:04 AM)
On Saturday, November 23, 2019 at 11:10:03 AM UTC+13, steve kargl wrote:
> Steve Lionel wrote:
> Hi Steve,
> I've opened a discussion on the J3 mailing list. Hopefully, a full borne
> interpretation request isn't needed.
> --
> steve


The latest 3 standards reveal that command_argument_count() was an inquiry function in f2003 13.7.21, but transformational in f2008 13.3.37 and f2018 16.9.51. Compiler_options() and compiler_version() were inquiry functions in f2008 13.8.2.6 and 13.8.2.7, but transformational in f2018 16.10.2.6 and 16.10.2.7. Why were they changed?
Steve Lionel (11-28-19, 01:45 AM)
On 11/27/2019 6:04 PM, jfh wrote:
> The latest 3 standards reveal that command_argument_count() was an inquiry function in f2003 13.7.21, but transformational in f2008 13.3.37 and f2018 16.9.51. Compiler_options() and compiler_version() were inquiry functions in f2008 13.8.2.6 and 13.8.2.7, but transformational in f2018 16.10.2.6 and 16.10.2.7. Why were they changed?


See , passed at meeting 186.
gah4 (11-28-19, 03:54 AM)
On Wednesday, November 27, 2019 at 3:45:20 PM UTC-8, Steve Lionel wrote:

(see)

> See , passed at meeting 186.


The short form is that inquiry functions should be compile-time
constant. Some functions that were inquiry and not compile time
constant are now transformational.

It might be interesting to have functions returning the compilation
date and compilation time. I believe some assemblers have this ability.

The C preprocessor has __TIME__ and __DATE__ which give the time and
date that the preprocessor is run. That isn't guaranteed to be the
same as compilation, but usually is. (At least when preprocessing
actual C code.) I suppose those could be used with Fortran programs
that use the C preprocessor.
Ron Shepard (11-28-19, 05:12 AM)
On 11/27/19 7:54 PM, gah4 wrote:
> It might be interesting to have functions returning the compilation
> date and compilation time. I believe some assemblers have this ability.


I do this with the following shell script, which is invoked by make with
a phony target every time the calling program is created with

##
## on every build, save the compile time environment.
##
cte_mod.F90: cte_mod.sh
cte_mod.sh > $@

..PHONY: cte_mod.F90

Here is the shell script. Some long lines will probably get wrapped.

#####################

#!/bin/sh

# shell script to create a *.F90 file with embedded
compile-time-environment information.

# output is written to stdout.
# usage: cte_mod.sh > cte_mod.F90

XsvnX=`svnversion -n`
XdateX=`date`
XhostX=`hostname -s`
XunameX=`uname -sr` # -a is over 132 characters, so keep it short.
XuserX=`whoami`

cat <<EOF | sed \
-e s/XSVNX/"$XsvnX"/ \
-e s/XDATEX/"$XdateX"/ \
-e s/XHOSTX/"$XhostX"/ \
-e s/XUNAMEX/"$XunameX"/ \
-e s/XUSERX/"$XuserX"/
module cte_mod

! this module defines some compile time environment (cte) parameters.

implicit none

! the following constants are defined by the script cte_mod.sh.

character(len=*), parameter :: cte_svn = 'XSVNX' ! svn source
code revision at compile time.
character(len=*), parameter :: cte_date = 'XDATEX' ! compile
date and time.
character(len=*), parameter :: cte_host = 'XHOSTX' ! compile
time hostname.
character(len=*), parameter :: cte_uname = 'XUNAMEX' ! OS info at
compile time.
character(len=*), parameter :: cte_user = 'XUSERX' ! user name
who compiled the code.

contains
subroutine cte_print( nlist )
! print out the entire list of cte* parameters to unit nlist.
implicit none
integer, intent(in) :: nlist
character(len=*), parameter :: cfmt='(2a)'

write(nlist,cfmt) 'cte_svn = ', cte_svn
write(nlist,cfmt) 'cte_date = ', cte_date
write(nlist,cfmt) 'cte_host = ', cte_host
write(nlist,cfmt) 'cte_uname = ', cte_uname
write(nlist,cfmt) 'cte_user = ', cte_user

return
end subroutine cte_print
end module cte_mod

#ifdef DEBUG
! compile with -DDEBUG to create a stand-alone test program.
program cte_test
use cte_mod
implicit none
call cte_print(6)
end program cte_test
#endif
EOF
robin.vowels (11-29-19, 05:12 AM)
On Thursday, November 28, 2019 at 12:54:18 PM UTC+11, ga...@u.washington.edu wrote:
> On Wednesday, November 27, 2019 at 3:45:20 PM UTC-8, Steve Lionel wrote:
> (see)
> The short form is that inquiry functions should be compile-time
> constant. Some functions that were inquiry and not compile time
> constant are now transformational.
> It might be interesting to have functions returning the compilation
> date and compilation time. I believe some assemblers have this ability.


The XPL compiler has had that facility pre 1970.
[..]
Similar Threads