(j3.2006) (SC22WG5.5448) [ukfortran] Response to TS ballot

[Bill Long]

On Feb 20, 2015, at 4:22 AM, John Reid <John.Reid at stfc.ac.uk> wrote:

> 
> 
> Malcolm Cohen wrote:
>> Two spectacular misses.
>> 
>> (1)
>> I wrote:
>> I note that in the case of executing code
>> outside (but called from) a CHANGE TEAM construct, "innermost" has no meaning.
>> 
>> To which you propose to make the edit:
>> [14:29] Replace "construct" by "innermost executing CHANGE TEAM
>> construct".
>> 
>> Innermost has a good meaning if you accepted my other recommendation, that this
>> effect be limited to code actually within a CHANGE TEAM construct, but you
>> rejected that.
>> 
>> So I have to repeat again, "INNERMOST" HAS NO MEANING in the case of executing
>> code outside (but called from) a CHANGE TEAM construct.  Innermost is a spacial
>> term referring to the placement of statements and constructs *Lexically Within*
>> other constructs.  It is not a temporal term referring to the order of
>> execution!
>> 
>> Perhaps you mean something like "active CHANGE TEAM construct that most recently
>> begun execution"?  In which case, that is something like what you need to say.
> 
> Agreed.


That is the intent.  Even though having multiple CHANGE TEAM constructs active at the same time will probably be rare, we need to account for the possibility. 

> 
>> There could well be MANY "innermost" CHANGE TEAM constructs being executed...
>> 
>> I further note that you went without my suggestion of "whose END TEAM statement
>> has a STAT= specifier".  It seems pointless to transfer control to an END TEAM
>> statement without a STAT= specifier since that will immediately cause error
>> termination.  If that is your intent, would it not be better to have error
>> termination immediately (at the erring code) rather than in the END TEAM
>> statement?  (The user will thank you for not throwing away the info about where
>> the problem occurred!)  If that is not your intent, well?

A reasonable option is to say that the image error stops immediately on a stall if there is no STAT= in the END TEAM.  Besides better traceback information, this allows the implementation to skip facilities that would be involved in unwinding the program state if it can see there is no STAT= in the END TEAM.  It basically gives the user another way of saying ?The algorithm is not recoverable, so chuck everything if an image fails."

> 
> In this case, I think we need to say that the image stays stalled for ever.
> 
>> 
>> (2)
>> I wrote:
>> - The syntax is "FAIL IMAGE <stop-code>".  I see no purpose in using the
>> <stop-code> BNF rule here.
>> 
>> You reply:
>> The <stop-code> BNF rule defines what the user can write.
>> 
>> ...which is PRECISELY my complaint.  WHY is the user being limited in this way?
>> Why on earth should this be required to be a constant expression?  The

Why do we have that requirement on STOP statements?  For a character <stop-code>, all of the cases are basically the same as

write (error_unit,*)  <stop-code>
flush (error_unit)
stop/error stop/fail image

which, of course, the user could code directly.  One advantage of requiring a constant is that it prevents the <stop-code> from being coindexed.  You really don?t want an image to stall while it is trying to fail (or stop or error stop).  Another is the practical one of being able to scan the program source for the text that was output so you can easily find where the image stopped (assuming the programmer didn?t use the same message on multiple statements).   An advantage of using a <stop-code> directly on the STOP/ERROR STOP/FAIL IMAGE statement instead of the sequence of three statements is that the three statements could be split across subprograms, again losing the benefit of locating the stopping point in the program source. 

I do agree that we don?t want the programmer to select a numerical exit status for the failed image.  The implementation needs control so it can send the right signal to indicate that this image is dead, but leave the rest of the program running.  But the implementation has the flexibility to not send the user-supplied value as the exit status in the FAIL IMAGE case. 


>> <stop-code> syntax is irregular and unnecessary.  Just make it an expression of

One could argue that i would be irregular to treat FAIL IMAGE as all that different from STOP and ERROR STOP.  They all have the effect of causing the image to not execute any more statements.  At least that was the rationale for including the <stop-code> in the first place. 

Cheers,
Bill


>> type integer or character.  Or even just type character (there is no "process
>> exit status" to be set here).
> 
> Agreed.
> 
> Cheers,
> 
> John.
> 
> _______________________________________________
> J3 mailing list
> J3 at mailman.j3-fortran.org
> http://mailman.j3-fortran.org/mailman/listinfo/j3

Bill Long                                                                       longb at cray.com
Fortran Technical Suport  &                                  voice:  651-605-9024
Bioinformatics Software Development                     fax:  651-605-9142
Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101