• name resolution of components within derived type definition

    From Peter Klausler US@21:1/5 to All on Fri Oct 14 10:58:26 2022
    F'2018 subclause 19.3.4 paragraph 1 says that "A component name has the scope of its derived-type definition" which seems pretty clear to me, but it doesn't seem to apply in the way that I would expect with many Fortran compilers. Shouldn't all of these
    uses of component names in a derived type definition resolve to the components with those names, rather than to the names in the enclosing scope?


    implicit double precision(b)
    integer, parameter :: k1 = selected_int_kind(1)
    integer, parameter :: kd = kind(0)

    integer(k1) :: foo

    type t
    integer(kd) foo
    integer(kind(foo)) bar
    integer(k1) :: baz = kind(foo)
    integer :: quux = kind(baz)
    end type
    type(t) x

    if (k1 == kd) stop 'rats'

    if (kind(x%bar) == k1) then
    print *, "kind(foo) resolves to outer foo for bar"
    else if (kind(x%bar) == kd) then
    print *, "kind(foo) resolves to inner foo for bar"
    else
    print *, "can't tell name resolution of foo for bar"
    end if
    if (x%baz == k1) then
    print *, "kind(foo) resolves to outer foo for baz"
    else if (x%baz == kd) then
    print *, "kind(foo) resolves to inner foo for baz"
    else
    print *, "can't tell name resolution of foo for baz"
    end if
    if (k1 == kind(0.d0)) then
    print *, "can't tell name resolution of baz for quux because k1 == kind(0.d0)"
    else if (x%quux == k1) then
    print *, "kind(baz) resolves to inner baz for quux"
    else if (x%quux == kind(0.d0)) then
    print *, "kind(baz) resolves to implicit outer baz for quux"
    else
    print *, "can't tell name resolution of baz for quux"
    end if
    end

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From FortranFan@21:1/5 to FortranFan on Fri Oct 14 11:48:59 2022
    On Friday, October 14, 2022 at 2:40:52 PM UTC-4, FortranFan wrote:
    ..
    There was a discussion at the J3 Fortran mailing list a couple of months ago *where* the editor of the standard (and the chair of the /DATA subgroup) and the de facto final authority on such matters in the language chimed in and whose brief response I
    reckon covers your inquiry here also: you know the drill, for further details there is the standard and the words in it.

    https://mailman.j3-fortran.org/pipermail/j3/2022-August/013836.html

    The following example might help in that the editor, per the comments above, would convey the processor here conforms in what it does with the program:

    implicit none !<-- note this
    integer, parameter :: ik = kind(0)
    type :: t
    integer(kind=ik) :: foo
    integer(kind=kind(foo)) :: bar !<-- what is 'foo' here?
    end type
    end

    C:\temp>gfortran -c p.f90
    p.f90:5:27:

    5 | integer(kind=kind(foo)) :: bar
    | 1
    Error: Symbol 'foo' at (1) has no IMPLICIT type

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From FortranFan@21:1/5 to Peter Klausler US on Fri Oct 14 11:40:49 2022
    On Friday, October 14, 2022 at 1:58:38 PM UTC-4, Peter Klausler US wrote:

    F'2018 subclause 19.3.4 paragraph 1 says that "A component name has the scope of its derived-type definition" which seems pretty clear to me, but it doesn't seem to apply in the way that I would expect with many Fortran compilers. Shouldn't all of
    these uses of component names in a derived type definition resolve to the components with those names, rather than to the names in the enclosing scope? ..

    @Peter Klausler US,

    There was a discussion at the J3 Fortran mailing list a couple of months ago whether the editor of the standard (and the chair of the /DATA subgroup) and the de facto final authority on such matters in the language chimed in and whose brief response I
    reckon covers your inquiry here also: you know the drill, for further details there is the standard and the words in it.

    https://mailman.j3-fortran.org/pipermail/j3/2022-August/013836.html

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Peter Klausler US@21:1/5 to All on Fri Oct 14 11:56:27 2022
    19.3.4 "A component name has the scope of its derived-type definition. Outside the type definition, it may also appear within a designator of a component of a structure of that type or as a component keyword in a structure constructor for that type."

    That first sentence must mean *something*, and the second sentence's "it may also appear" implies that a component name *can* appear with a derived type definition.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From FortranFan@21:1/5 to Peter Klausler US on Fri Oct 14 12:46:24 2022
    On Friday, October 14, 2022 at 2:56:29 PM UTC-4, Peter Klausler US wrote:

    19.3.4 "A component name has the scope of its derived-type definition. Outside the type definition, it may also appear within a designator of a component of a structure of that type or as a component keyword in a structure constructor for that type."

    That first sentence must mean *something*, and the second sentence's "it may also appear" implies that a component name *can* appear with a derived type definition.

    You can seek further clarification with the committee but chances are nearly 100% that

    a) re: "That first sentence must mean *something*", the "something" will *not* extend to instructions such as 'integer(kind(foo)) bar' in the code snippet in your original post.

    b) re: "the second sentence's "it may also appear"" does not refer to "type definition" but to a "structure" and a constructor for it where the "structure" - per the standard - is a scalar data object of a derived type.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Peter Klausler US@21:1/5 to FortranFan on Fri Oct 14 12:59:07 2022
    On Friday, October 14, 2022 at 12:46:26 PM UTC-7, FortranFan wrote:
    On Friday, October 14, 2022 at 2:56:29 PM UTC-4, Peter Klausler US wrote:

    19.3.4 "A component name has the scope of its derived-type definition. Outside the type definition, it may also appear within a designator of a component of a structure of that type or as a component keyword in a structure constructor for that type."

    That first sentence must mean *something*, and the second sentence's "it may also appear" implies that a component name *can* appear with a derived type definition.
    You can seek further clarification with the committee but chances are nearly 100% that

    a) re: "That first sentence must mean *something*", the "something" will *not* extend to instructions such as 'integer(kind(foo)) bar' in the code snippet in your original post.

    b) re: "the second sentence's "it may also appear"" does not refer to "type definition" but to a "structure" and a constructor for it where the "structure" - per the standard - is a scalar data object of a derived type.

    https://dictionary.cambridge.org/us/dictionary/english/also - adverb, "in addition to".

    Further, type parameter names of a type are in exactly the same scope as its component names, and type parameter names obviously can be used in the scope of a type definition.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to Peter Klausler US on Fri Oct 14 14:00:22 2022
    On Friday, October 14, 2022 at 10:58:38 AM UTC-7, Peter Klausler US wrote:
    F'2018 subclause 19.3.4 paragraph 1 says that "A component name
    has the scope of its derived-type definition" which seems pretty clear to me, but it doesn't seem to apply in the way that I would expect with many
    Fortran compilers. Shouldn't all of these uses of component names in a derived type definition resolve to the components with those names,
    rather than to the names in the enclosing scope?

    (snip

    type t
    integer(kd) foo
    integer(kind(foo)) bar
    integer(k1) :: baz = kind(foo)
    integer :: quux = kind(baz)
    end type

    This isn't so obvious to me.

    It might be that the foo inside the structure definition doesn't exist
    until after the "end type".

    There is a special rule in C that allows structures to have pointers
    to their own struct type, even though the struct isn't defined yet.

    I suspect you have to read the rules a lot more carefully, to know
    exactly when the inside foo exists, enough for kind to apply.
    (And as your example shows, it might be different for KIND
    than for initializers.)

    It is hard for compiler writers to get this right, and so
    my best guess is 50% chance you are right and the compiler
    wrong.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Peter Klausler US@21:1/5 to All on Fri Oct 14 15:08:54 2022
    On Friday, October 14, 2022 at 2:00:25 PM UTC-7, gah4 wrote:
    It is hard for compiler writers to get this right, and so
    my best guess is 50% chance you are right and the compiler
    wrong.

    Well, I'm writing the compiler, so I hope that it's both or neither.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From FortranFan@21:1/5 to Peter Klausler US on Sat Oct 15 08:09:43 2022
    On Friday, October 14, 2022 at 3:59:09 PM UTC-4, Peter Klausler US wrote:

    On Friday, October 14, 2022 at 12:46:26 PM UTC-7, FortranFan wrote:
    ..
    b) re: "the second sentence's "it may also appear"" does not refer to "type definition" but to a "structure" and a constructor for it where the "structure" - per the standard - is a scalar data object of a derived type.
    https://dictionary.cambridge.org/us/dictionary/english/also - adverb, "in addition to".

    The "standardese" charters its own course, it feels free to supersede the dictionary or ordinary usage of terms and phrases.


    Further, type parameter names of a type are in exactly the same scope as its component names, and type parameter names obviously can be used in the scope of a type definition.

    In the case of a type parameter name, the standard states, "A type parameter may be used as a primary in a specification expression (10.1.11) in the derived-type-def . A kind type parameter may also be used as a primary in a constant expression (10.1.12)
    in the derived-type-def ." This will likely be pointed out as being applicable and also different from the case with the component name, the latter i.e., the component name being used for example in 'integer(kind(foo)) bar' in the code snippet in the
    original post:

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Peter Klausler US@21:1/5 to FortranFan on Sat Oct 15 13:44:39 2022
    On Saturday, October 15, 2022 at 8:09:45 AM UTC-7, FortranFan wrote:
    https://dictionary.cambridge.org/us/dictionary/english/also - adverb, "in addition to".
    The "standardese" charters its own course, it feels free to supersede the dictionary or ordinary usage of terms and phrases.

    Ok, if you've altered the meaning of the word "also" in the standard, what does it now mean in this context?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From FortranFan@21:1/5 to Peter Klausler US on Sat Oct 15 17:35:36 2022
    On Saturday, October 15, 2022 at 4:44:41 PM UTC-4, Peter Klausler US wrote:

    On Saturday, October 15, 2022 at 8:09:45 AM UTC-7, FortranFan wrote:
    https://dictionary.cambridge.org/us/dictionary/english/also - adverb, "in addition to".
    The "standardese" charters its own course, it feels free to supersede the dictionary or ordinary usage of terms and phrases.
    Ok, if you've altered the meaning of the word "also" in the standard, what does it now mean in this context?


    Not sure what you're getting at, however re: the component name, again here's what you can review:

    --- text on the J3 mailing list reply from the Editor ---
    ".. A “bare” type component name can appear only

    1. as the name of the component being defined by a component definition statement;
    2. as a keyword in a structure constructor for that type.
    .."
    --- end text ---

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)