[J3] 18-156

[Bill Long]

> On Feb 26, 2018, at 4:25 PM, Clune, Thomas L. (GSFC-6101) via J3 <j3 at mailman.j3-fortran.org> wrote:
> 
> 
>> On Feb 26, 2018, at 5:01 PM, Van Snyder via J3 <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?

You remember correctly.  The ?Proper enumerated types? feature is on the ?continue to do work? list in 18-156.   What the ultimate feature looks like, or whether it survives the WG5 selection process will not be known until the June meeting at the earliest. 

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

The degree trig functions are for programmers who know what they are doing.  Unrelated to UNITS. Particularly since Radians intentionally do not have units. 



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

The KIND values for LOGICAL are processor dependent, and the order in LOGICAL_KINDS is processor dependent. 

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

Correct. 

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

Correct. 

> But I would encourage you to set your colleagues expectations appropriately, esp. with regard to that first item.

Van knows that UNITS were killed at the London WG5 meeting.  I assume he informed his colleagues that this was a dead issue. 

Cheers,
Bill


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

Bill Long                                                                       longb at cray.com
Principal Engineer, Fortran Technical Support &   voice:  651-605-9024
Bioinformatics Software Development                      fax:  651-605-9143
Cray Inc./ 2131 Lindau Lane/  Suite 1000/  Bloomington, MN  55425