[J3] 18-156

[Clune, Thomas L. GSFC-6101]

On Feb 26, 2018, at 5:01 PM, Van Snyder via J3 <j3 at mailman.j3-fortran.org<mailto:j3 at mailman.j3-fortran.org>> wrote:

I had to leave Thursday night so I wasn't present to comment on Friday.

Propoer enumerated types are not a BIND(C) feature.  We already have
BIND(C) ENUM, introduced to make it easier to write C programs in
Fortran.  BIND(C) ENUMs can't be used for generic resolution, and have
no type safety at procedure references.

And I thought the ?improved? ENUM concept was favorably reviewed.   Am I remembering incorrectly?

?


I don't understand how degree trigonometric functions are helpful
without units support.  Units support would allow generic resolution to
select the correct one.

If, upon reflection, you really do not see how the degree trig functions are helpful without units support, please contact me.   I?ll either phone or write something up.   Seems fairly self-evident to me, and I?m thinking that this is just a back-door argument into a well-trodden tangent.

In addition to LOG8 etc, SELECTED_LOGICAL_KIND with an argument that
gives the minimum number of bits, which the processor is free to
interpret as the maximum too.

It was argued that this is very different than what is the case with the other SELECTED_*_KIND functions.      Since storage size is the _only_ difference among LOGICAL kinds, one can simply choose the one that is desired directly.   Of course, you?ll need a small bit of logic to guard against the ones that are not supported:

INTEGER, PARAMETER :: MY_LOGICAL_KIND =  MINVAL(LOGICAL_KINDS)

This might need tweaking.  I?m not certain if LOGICAL_KINDS is required to put the available kinds in any particular order, nor that the KINDS themselves are required to be monotonically increasing.    A more robust solution might then be to list the ones you want in order of preference:

INTEGER, PARAMETER :: POSSIBLES(*) = [LOGICAL8, LOGICAL16,kind(.true.)]
INTEGER, PARAMETER :: SUPPORTED(*) = PACK(POSSIBLES, POSSIBLES > 0)
INTEGER, PARAMETER :: MY_LOGICAL_KIND =  SUPPORTED(1)

If I understand correctly, there might be some value in an intrinsic that simplifies this.   But the committee seemed united that it would not be called ?SELECTED_LOGICAL_KIND?.



I didn't have any time to consult with my colleagues when Steve said
"pick five for tomorrow," so I guessed.  My priorities weren't the same
as theirs.  Instead of ranges and views, they told me I should have
asked for.

1. Units
2. Support for containers
  2a. coroutines and iterators
  2b. updaters
3. Generalized subscripts -- subclause 2.4.1 in 18-119


There are more meetings before things are finalized.   But I would encourage you to set your colleagues expectations appropriately, esp. with regard to that first item.

- Tom






_______________________________________________
J3 mailing list
J3 at mailman.j3-fortran.org<mailto:J3 at mailman.j3-fortran.org>
http://mailman.j3-fortran.org/mailman/listinfo/j3_mailman.j3-fortran.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.j3-fortran.org/pipermail/j3_mailman.j3-fortran.org/attachments/20180226/28fa76f9/attachment-0001.html>