The stdlib_ascii module uses INT_KINDS instead of a list of logical kinds to generate to_string(logical)

[arjenmarkus]

Generating the to_string function for logical arguments
The code for stdlib_ascii contains the following code:

    #:for kind in INT_KINDS
    !> Represent an logical of kind ${kind}$ as character sequence
    pure function to_string_logical_${kind}$(val) result(string)
        integer, parameter :: ik = ${kind}$
        logical(ik), intent(in) :: val
        character(len=1) :: string

        string = merge("T", "F", val)
    end function to_string_logical_${kind}$
    #:endfor

Clearly instead of INT_KINDS a macro LOG_KINDS should be used.

However, the file common.fypp which defines these macros lacks a list for logical kinds.

Expected behaviour
The file stdlib_ascii should have:

    #:for kind in LOG_KINDS
    !> Represent an logical of kind ${kind}$ as character sequence
    pure function to_string_logical_${kind}$(val) result(string)

And the file common.fypp should have:

#! Logical kinds to be considered during templating - fill in the correct names
#:set LOG_KINDS = [...] 
   
#! Logical types to be considered during templating
#:set LOG_TYPES = ["logical({})".format(k) for k in LOG_KINDS]

Technical Details
The adjustments to the code should be obvious

Compiler version
Independent of the compiler

Platform and Architecture
All platforms - it concerns the source code

[awvwgk]

I used the INT_KINDS from the common.fypp because we don't have kind parameters for logical yet. In principle they should be the same as for integers from my understanding, so adding an alias in common.fypp with

#:set LOG_KINDS = INT_KINDS

would probably sufficient. Or am I missing something here?

[arjenmarkus]

Not sure, is that guaranteed by the standard? In that case we ought to be able to rely on that alias. I came across it when I was working on my string_list module. Op do 3 jun. 2021 om 22:12 schreef Sebastian Ehlert < ***@***.***>:

…

I used the INT_KINDS from the common.fypp because we don't have kind parameters for logical yet. In principle they should be the same as for integers from my understanding, so adding an alias in common.fypp with #:set LOG_KINDS = INT_KINDS would probably sufficient. Or am I missing something here? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#423 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAN6YRYOV6CESSD2J6LLYITTQ7OZHANCNFSM46BM5XUA> .

[jvdp1]

Here is what is mentioned in the section iso_fortran_env of the standard:

16.10.2.20 LOGICAL_KINDS
20 1 The values of the elements of the default integer array constant LOGICAL_KINDS are the kind values supported
21 by the processor for variables of type logical. The order of the values is processor dependent. The rank of the
22 array is one, its lower bound is one, and its size is the number of logical kinds supported.

I didn't find such definitions as for int8, ...,int32,...int68,...real32. So,I guess that the best is to add logical kinds in stdlib_kinds, based on iso_fortran_env

[arjenmarkus]

So, no intrinsic connection between the integer kinds and the logical ones. I can imagine that some compilers would use the same kinds but I would say it is equally likely then that some compilers have two separate sets. Op vr 4 jun. 2021 om 08:29 schreef Jeremie Vandenplas < ***@***.***>:

…

Here is what is mentioned in the section iso_fortran_env of the standard: 16.10.2.20 LOGICAL_KINDS 20 1 The values of the elements of the default integer array constant LOGICAL_KINDS are the kind values supported 21 by the processor for variables of type logical. The order of the values is processor dependent. The rank of the 22 array is one, its lower bound is one, and its size is the number of logical kinds supported. I didn't find such definitions as for int8, ...,int32,...int68,...real32. So,I guess that the best is to add logical kinds in stdlib_kinds, based on iso_fortran_env — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#423 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAN6YR7PJ5BT2SAH744OMUTTRBXFHANCNFSM46BM5XUA> .

[jvdp1]

It seems to be the case indeed:

• From Intel 's description of logical_kinds in iso_fortran_env:

Is the kind type parameter supported by the processor that is used when defining variables of type logical. This is a default integer array constant. The rank of the array is one, its lower bound is one, and its size is the number of logical kinds supported. In Intel® Fortran its value is [1, 2, 4, 8].

• From NAG:

 INTEGER,PARAMETER :: logical_kinds(4) = integer_kinds
Array listing all valid kind type parameter values for LOGICAL type.

[awvwgk]

Since there is no selected_logical_kind intrinsic it is somewhat hard to produce the kind parameters ourselves. Additionally, there are no named constants for logical kind parameters available in the iso_fortran_env module (i.e. logical_kinds doesn't contain the constant names but only their values).

The more important question is whether we need different logical kinds beyond the default one. A potential use case is the c_bool kind.

[arjenmarkus]

I would say that unless we find a different solution, the default and the c_bool kind should be supported. That may turn out to be too little, but the alternative is a potential build failure. Suppose the compiler does not support a logical kind of 8 bytes, say, Op vr 4 jun. 2021 om 09:45 schreef Sebastian Ehlert < ***@***.***>:

…

Since there is no selected_logical_kind intrinsic it is somewhat hard to produce the kind parameters ourselves. Additionally, there are no named constants for logical kind parameters available in the iso_fortran_env module (*i.e.* logical_kinds doesn't contain the constant names but only their values). The more important question is whether we need different logical kinds beyond the default one. A potential use case is the c_bool kind. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#423 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAN6YR72VE3WAN44FPJRIF3TRCAAFANCNFSM46BM5XUA> .

[awvwgk]

Just out of curiosity which Fortran compiler does currently fail to compile logical(int64)?