:: in MODULE PROCEDURE statements

[Dick Hendrickson]

Someone recently asked whether or not the :: was allowed in a MODULE
PROCEDURE statement. As far as I can tell, the "::" was not allowed in
F2003 MODULE PROCEDURE statements and is now optional in F2008.

Sorry for replying off-thread, but my newsreader lost the original post.

Dick Hendrickson

[dpb]

On 10/14/2012 10:23 AM, Dick Hendrickson wrote:
> Someone recently asked whether or not the :: was allowed in a MODULE
> PROCEDURE statement. As far as I can tell, the "::" was not allowed in
> F2003 MODULE PROCEDURE statements and is now optional in F2008.

...

It's never been clear to me whether there's/re a place/s where the :: is
actually required; seems like it's always optional in the places I can
remember. I presume there must be _somewhere_ to be required for syntax
disambiguation or it wouldn't have been introduced???

There's also the thing I've complained in the past about of the "::" vis
a vis the one or two places where there's just a ":" -- I'd have like to
have seen it be the same everywhere. In a quick search I can't find the
thread of probably a couple years ago (or maybe even longer) where I
think Richard M did at least part of the explanation but I've slept
since then... :)

--

[Richard Maine]

dpb <no...@non.net> wrote:

> On 10/14/2012 10:23 AM, Dick Hendrickson wrote:
> > Someone recently asked whether or not the :: was allowed in a MODULE
> > PROCEDURE statement. As far as I can tell, the "::" was not allowed in
> > F2003 MODULE PROCEDURE statements and is now optional in F2008.
> ...
>
> It's never been clear to me whether there's/re a place/s where the :: is
> actually required; seems like it's always optional in the places I can
> remember. I presume there must be _somewhere_ to be required for syntax
> disambiguation or it wouldn't have been introduced???

It is required in a type declaration statement that has any attr-specs.
That's not said in words; it just falls out of the bnf. If it were not
required, consider... hmm. When I try to do an example off the top of my
head, the required commas do disambiguate, though the difference between

real, save, x

and

real save, x

would be pretty tricky (fixed source form; I recall bitching that
several bits of syntax could be simpler if they were restricted to free
source form. But that got zero support, even when they were new syntax
bits that could not directly be a problem for compatibility with old
code). I swear I recall some cases that were actually ambiguous without
that requirement, but my off-the-top-of-my-head examples don't show
that. Anyway, the standard does require the double colon there.

Also, C523 (of f2003)

"If <initialization> appears, the double-colon separator shall
appear..."

For that one, making an example of the ambiguity is much simpler... as
in it is hard to do an example that isn't ambiguous (hard as in I don't
see how).

real x = 1.234

Sure looks like an assignment statement to me (in fixed source form).

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain

[Ron Shepard]

In article <k5f14d$os$1...@speranza.aioe.org>, dpb <no...@non.net>
wrote:

> It's never been clear to me whether there's/re a place/s where the :: is
> actually required; seems like it's always optional in the places I can
> remember.

integer, intent(inout), allocatable, dimension(:), i

There are four possible places for the ::, and the above means
something very different for each one of them.

$.02 -Ron Shepard

[glen herrmannsfeldt]

The following compiles, I didn't try running it:

subroutine this(intent, dimension, inout)
integer intent(inout), allocatable, dimension(:), i
dimension=intent
write(*,*)(dimension(i),i=1,inout)
end

That is one comma less than above, and no colons.

-- glen