Can a BLOCK construct be within an ASSOCIATE construct and recognize the associations?

[FortranFan]

The following code with a BLOCK construct (Fortran 2008) within an ASSOCIATE construct fails to compile when the associate-name is used inside the block.  Is this only to be expected per the standard?  I couldn't find anything in the standard that says this is not allowed.

program p

   implicit none

   character(len=:), allocatable :: foo

   foo = "Hello World!"

   asc: associate ( s => foo )

      print *, " foo says ", s

      blk: block

         print *, " foo says ", s

      end block blk

   end associate asc

   stop

end program p

1>Compiling with Intel(R) Visual Fortran Compiler XE 15.0.2.179 [Intel(R) 64]...
1>p.f90
1>C:\..\p.f90(15): error #6404: This name does not have a type, and must have an explicit type.   
1>compilation aborted for C:\..\p.f90 (code 1)

[Steven_L_Intel1]

Seems to me that this ought to work. I'll report it as a possible bug. Issue ID is DPD200366820.

[FortranFan]

Thanks Steve.

A question: is the support for EXIT statement in the BLOCK construct on the near-term development agenda for Intel Fortran?

[Steven_L_Intel1]

It's on our list - can't say more right now.

[Steven_L_Intel1]

The issue with BLOCK inside ASSOCIATE has been fixed for a release later this year.

[FortranFan]

Very good, thanks.

[Steven_L_Intel1]

I'm now told that you can expect the fix for this to be in Update 3, due in May.

[FortranFan]

Even better, thanks!

If you give a mouse a cookie, he'll want milk with it.. :-)) ...waiting for the EXIT in BLOCK now.. it will nicely complete the code section in one of our libraries where the issue in the original post arose. 

[Steven_L_Intel1]

What would you like in your milk?

[FortranFan]

Steve Lionel (Intel) wrote:

What would you like in your milk?

Oh, lots of sweet things, varies by the day! :-)  But most importantly, a straw to drink it with!  

So how about EXIT with ASSOCIATE construct next?!

And how about the Intel Fortran compiler leaders giving the following a good thought for consideration in a future standard (post-2015 of course): a language enhancement to be able to combine ASSOCIATE and BLOCK constructs (see pseudocode below vis-a-vis the one in the original post)!! Then either table it on behalf of the mouse at a future Fortran standards meeting or provide a brief commentary here on why it might be a bad idea!

   type(..) :: foo

   ..

   blk: block ( s => foo%bar%foobar )

      type(..) :: tmpfoo

      !.. some operations with s and tmpfoo

      !.. overwrite s
      s = ..

      exit blk

   end block blk

[IanH]

I have previously wondered why, for Fortran 2008, the syntax for a block was not altered to permit a specification part followed by an execution part.  This would mean that any construct that contains a block (if constructs, do constructs, associate constructs, critical constructs, etc...) could then have variables local to it.  The block construct would then just be used when you wanted a block "in-line".

I have a recollection of coming up with an example of why this wasn't possible though (perhaps ambiguous source, or a change in interpretation of source that is currently conforming?), but I'm stuffed if I can remember what it was.  Then again, I also have a recollection of taking the bins out last night, but (after the rubbish truck has been ) I see that I was mistaken.

[FortranFan]

To me, an ASSOCIATE construct feels similar to and like a subset of a BLOCK construct and I wonder if an expanded BLOCK can supersede ASSOCIATE.

[jimdempseyatthecove]

IanH, FortranFan,

Other than for stylistic reasons, what would the pros and cons be of using a contained procedure?

IOW cut what is in the desired block, insert a CALL YourContained(...), and add a CONTAINS;subroutine YourContained(...

Jim Dempsey

[FortranFan]

jimdempseyatthecove wrote:

IanH, FortranFan,

Other than for stylistic reasons, what would the pros and cons be of using a contained procedure?

IOW cut what is in the desired block, insert a CALL YourContained(...), and add a CONTAINS;subroutine YourContained(...

Jim Dempsey

Jim,

I don't know if you'd consider convenience and effort while coding and flow in code to be part of style, but these are a couple of reasons why I'd personally prefer block constructs over contained procedures.  I've not explored contained procedures enough to know if there are any other cons.  Now many of the places where I use ASSOCIATE construct, it will be rather unwieldy to use a contained procedures. Ultimately a lot of these aspects are a matter of "syntactic sugar", hence my comment about "sweet things" with milk! :-)

[jimdempseyatthecove]

I like your suggestion in #10

IMHO the standards committee could have resolved your issues if they permitted the BLOCK construct to exist like you present in #10:

(**** warning, hypothetical language extension ****)

[name:] BLOCK [ ([associate-name=>selector[, associate-name=>selector[...]]]) ]
  [specification-part]
  block
END BLOCK [name]

Where, when one or more associate-name=>selector are provided within ()'s that the type of the associate-name is implicitly declared (and need not be duplicated in the specification-part. The argument associations evaporate at the end of the block where they were defined.

It should also be considered as an extension, a BLOCK function:

[name:] [x = ] BLOCK [ ([associate-name=>selector[ ,associate-name=>selector[...]]]) [RESULT(r)]]

Jim Dempsey

[Steven_L_Intel1]

Jim, your last suggestion is similar to "lambda functions" in C++. I have a hard time seeing the committee warming up to that, but one never knows.

[jimdempseyatthecove]

Steve,

I'd like to suggest that Intel consider adding this as an Intel extension to the language (and providing this to gfortran). Momentum is a good argument for a standards committee to do something. This suggestion would not add a new keyword. Although you might require the use of RESULT(r) in the block function declaration to disambiguate from an array or same named function as "BLOCK".

Someone such as yourself would have to ascertain potential issues with the suggestions in #15 (based on #10).

Jim Dempsey

[Steven_L_Intel1]

Jim, we just don't do that (major language extensions) anymore, and most of our customers would not use such a thing if it wasn't supported by at least three if not four different compilers. It's not as if we are lacking for things to do in the current (and upcoming) standard. We already have the next two if not three releases mapped out.

I will make a note of this in a list I am compiling of proposals for the next standard.

[FortranFan]

Good suggestions and discussion, Jim and Steve.  The extension of BLOCK as a lambda function is cool; I trust the standards committee looks at proposals in terms of their various aspects involving functional benefits and language evolution, etc. and not similarity with C++ to which there might be an aversion! 

Yes, for a while now, I have to come realize things have changed with the Fortran standard and compiler vendors and the kind of extensions (some really good) that were offered by many vendors in their FORTRAN 77 implementations (which were later incorporated into the standard) may no longer be offered.  But at the same time, most folks (including myself) may not want to use a vendor-specific extension any longer.  Nonetheless, the compiler vendors, at least the major ones such as Intel, can still play a big role in standards development by internally evaluating suggestions by their customers and their own teams followed by proposal of such enhancements to the committee and using their "technical" influence to get good ideas accepted.

Hence it is great to see Steve write, "I will make a note of this in a list I am compiling of proposals for the next standard." - a big "thank you" to Steve and Intel for doing this - appreciate it greatly.