Figuring out C750 & C754

#1

In Fortran 2018’s definition of derived type component specifications we have this constraint:

C750 (R740) Each bound in the explicit-shape-spec shall be a specification
expression in which there are no references to specification functions or the
intrinsic functions ALLOCATED, ASSOCIATED, EXTENDS_TYPE_OF, PRESENT,
or SAME_TYPE_AS, every specification inquiry reference is a constant expression,
and the value does not depend on the value of a variable.

I’m curious what you all might think the phrase “does not depend on the value of a variable” means in the context of this example.

module m
  type :: t(len)
    integer, len :: len
    integer :: a(len)
  end type
 contains
  subroutine subr(j)
    integer, intent(in) :: j
    type(t(j)) :: x
  end subroutine
end module

The declaration of the component a in the PDT t depends on the value of the length type parameter len, and at the declaration of the variable x, the value of len does depend on the incoming value of the dummy argument j. So does this example violate C750, because it causes a bound to be transitively and eventually dependent on the value of a variable?

(Most Fortran compilers accept this usage.)

There’s a similar question that can be raised about C754.

#2

For explicit-shape-spec there is also this rule (or exception) to C750:

C831 (R816) An explicit-shape-spec whose bounds are not constant expressions 
shall appear only in a subprogram, derived type definition, BLOCK construct,
or interface body.

Your example falls under this rule. You have an explicit-shaped array a(len) but len is passed as an argument in both a derived type and a subprogram.

#3

No, not per my understanding.

Unless I’m mistaken, one can see constraint C750 as applying to a type definition of a derived type component. Whereas the example you show with type(t(j)) :: x is a variable declaration statement in a subprogram scope where different semantics with what one can call automatic objects come into play. So there is no non-conformance of the Fortran standard here.

#4

To elaborate further, consider the following code variant and the comments in code as to what the standard permits and does not:

module m
   type :: t(len)
      integer, len :: len
      integer :: a(len)
   end type
   integer, parameter :: a=1, b=2, c=3
   integer :: n
   type :: foo
      type(t(len=a**2+2*b+c)) :: y !<-- Ok because of constant expression
      !type(t(len=n)) :: z !<-- Not ok
   end type
contains
   subroutine subr(j)
      integer, intent(in) :: j
      type(t(j)) :: x !<-- Ok
   end subroutine
end module
#6

That is a fair question though I didn’t appreciate it as such from the original post.

Nonetheless, when it comes to wording, it is not just this one, but there are so many sections where the wording can and must be improved in the standard (immediate example: everything with POINTERs and TARGETs). It is a very deep, philosophical matter though, one that hits upon so aspects including individual sensibilities (editor) and especially diversity and inclusivity.

I am someone for whom English is a 6th language. It took so much effort to comprehend the regular written and spoken words in this language in the first place. But the standardese in ISO IEC 1539-1:2018 ever proves so difficult. On top of it, it takes so much effort to understand processor implementations vis-a-vis the standard and to decode and diagnose the deviations relative to one’s understanding of the standard.

For example, I’ve submitted over a dozen support requests with a commercial Fortran compiler in the last couple of weeks itself. And it takes even more excruciating amount of effort to convince the implementors there are implementation issues which they need to address in their product for the sake of the customer i.e., the Fortran practitioner.

And in so many of these instances, to me it appears to come back to the standard itself and wish the wording was better, or there were more notes to elaborate further on the standardese or specific phraseology adopted in a given section.

3 Likes
#7

I agree, the Fortran standard is extremely difficult to read and understand. My experience of it is similar to when I’m reading corporate state law.

1 Like
#9

Suggestions for clearer wording are always welcomed, but in many cases I note that the suggestions unintentionally change the definition, which is not good.

For me, the biggest problem of the standard is that you must keep the entire thing in your head to get a definitive answer. For example, @stavros noted a constraint in a different clause (chapter) that relates to the syntax rule asked about. Often, I have been reading a section and misunderstood something because I needed to see some text that was 100+ pages away!

The alternative, unfortunately, is to say something more than once, which makes it likely one of the places will be wrong! I have occasionally been successful at adding notes where something was especially troublesome for implementors and/or users. (Notes are not “normative text”, so they don’t change the meaning of the standard, but they can be helpful in highlighting issues.)

Yes, “standard speak” is difficult, even for those of us whose native language is English and have been immersed in the Fortran standard for decades. Some of this is foisted on us by ISO rules, but most is an honest attempt to say exactly what we mean and not introduce inconsistencies.

5 Likes