(j3.2006) more enhancements to the Fortran Standard

[Dan Nagle]

Hi,

For those who don't know, KAPL is Knowles Atomic Power Lab.
See http://www.knollslab.com/ for details.

I have chatted via email with this guy off-and-on
for some time now.  He may be interested in membership.  :-)

He has some features, which, of course, we can't consider now.
I forward them to the list for the record.

Hi,

I'm glad you wrote.  I'll try to answer.  :-)

On Sep 18, 2009, at 3:08 PM, Brocci, R. A. wrote:

> Before I get to the suggestions, please tell me more about the cost  
> of being able to post my suggestions directly. You mentioned there  
> was a fee in your 29 May email. (Perhaps I can convince my  
> management that the cost is worthwhile.)

If you have an interest in Fortran, I can put your email
on a "members and friends" email list.  I cannot put your name
on a members-only list.  Let me know if that suits.

The cost of membership is 1200US$, payable to INCITS.
If you want to join J3, I will help you make contact.

Under the rules, membership fees are charged on a from-January-to-
December basis.  You must have one "observer" meeting
before being allowed to vote.  We have a November meeting,
with details at www.j3-fortran.org, if you can attend, we can count that
as your observer meeting.
>
> And, how does one go about just reading what gets posted, and is  
> there an associated cost?
>
> Now, here are six (6) more suggested enhancements to the Fortran  
> Standard:

You have obviously given this some thought, so I am disappointed
to have to tell you that it is too late for making any change
to the Fortran 2008 revision.  I will forward your email
to the J3 list (which will archive it in addition to making it
available to the membership).

Currently, J3 is working on Further Interoperability with C,
in conjunction with the MPI Fortran Interface subgroup.  We
are trying to define new features to make Fortran play well
with MPI (and other C libraries with "choice" arguments (void*
and count*sizeof) and asynchronous semantics).

Also, the coarray features were split into two sets, the first set
is in the Fortran 2008 draft, the second set will be published  
separately.
While the general outlines are done, the details are not.

Help on any of these documents will be appreciated.

We amy start a features list for a new revision sometime
after 2012, if we adhere to our current plans.

>
> 1)  To the any function, add the optional intent(out) integer  
> argument LOC=VAL, where VAL shall contain the mask-array index for  
> which the mask is true.
>
> Whether or not VAL is a scalar, or an array of the same rank as the  
> mask-array is an open question. (In my long-time counterpart of this  
> function, VAL is a scalar that I've decoded into the actual array  
> indices when I've needed them.)
>
> For me at least, this removes the ever-present need to subsequently  
> invoke the maxloc or minloc functions. That is, I'm almost always  
> interested in not only its truth, but where it is true.
>
> 2)  To the count function, add the optional intent(out) integer  
> arguments LOC1=VAL1, LOC2=VAL2, and LOCS=VALS, where VAL1 and VAL2  
> shall contain the first and last mask-array indices for which the  
> mask is true, and VALS shall contain all of the indices for which  
> the mask is true to the extent that its size allows. (That is, and  
> as an example, VALS might not have the size to contain VAL2.)
>
> Whether or not VAL1, VAL2 are scalars, or arrays of the same rank as  
> the mask-array is an open question, as is whether or not VALS is a  
> rank 1 array or an array of the same rank as the mask-array. (In my  
> long-time counterpart of this function, VAL1 and VAL2 are scalars,  
> and VALS is a rank 1 array, all of which I've decoded into the  
> actual array indices when I've needed them.)
>
> Again, this removes the ever-present need to subsequently invoke the  
> maxloc and minloc functions to obtain the VAL1 and VAL2 indices.
>
> 3) Similar to the above suggestion for the any function, add the  
> optional integer intent(out) argument LOC=VAL to the maxval and  
> minval functions, where VAL shall be the mask-array index where the  
> maximum and minimum values occur.
>
> 4) Add the optional intent(out) type-T argument VAL=X to the maxloc  
> and minloc functions, where X shall be the maximum and minimum value  
> respectively in the mask-array, rather than force the subsequent use  
> of the illustrative
>
>    X = Y(maxloc_return_value_1,maxloc_return_value_2,...
>
> statement.
>
> 5) Enhance the RESULT clause of the function statement by allowing  
> initialization of the return value, as in the illustrative
>
>        integer function XYZ ( ... )   RESULT  ( fvalue = 0 )
>
> declaration statement, and allow fvalue to be "dimensioned" as in  
> the illustrative
>
>        integer function XYZ ( ... )   RESULT  ( fvalue(2) = 0 )
>
> declaration statement.
>
> For example, with F90 I can at least consider recasting my long-time  
> minmax function into the
>
>    (/ minval, maxval /) = minmax( ... )
>
> form, which I think is its natural more form, and for which the  
> dimension capability would enable me to use the
>
>    fvalue = (/ minval, maxval /)
>
> minmax "return" statement -- as opposed to the (seemingly) now- 
> required
>
>    function minmax ( ... )
>    ...
>    integer :: minmax(2)
>    ...
>    minmax = (/ minval, maxval /)
>
> form.
>
> 6) Make the old VAX run-time format descriptor <N>[AIFE]W...  
> extension part of the Standard, where N is a run-time scalar integer  
> variable that is defined within the scope of the format descriptor,  
> and says for example, read/write N integer values in fields of width  
> W.
>
> Some current compilers -- e.g., Intel's -- accept this descriptor,  
> so it would be preferable to maintain the <...> syntax in the  
> Standard.
>
> Thanks for your time and assistance.
>
>
>
> Tony Brocci   18 Sep 2009
> KAPL
> PO Box 1072,  Mail Stop 122
> Schenectady, NY  12301
> 518-395-6682
> brocci at kapl.gov

-- 
Cheers!

Dan Nagle