[J3] Consideration of Paper 18-242 at Meeting 218 (Was: 18-242)

[Malcolm Cohen]

Admitted not being a great fan of the original idea anyway… but *if* we’re going to pursue this…

 

I definitely concur with Van that a compound-loop DO statement would fill a much-needed gap.

 

I also agree with Van’s characterisation that in general we use commas when serial execution is implied, and colons when it is not.

 

However, arguing about syntax now is putting the cart before the horse.  The order is:

1.	Requirements (including “use case” examples).  This will mention something along the lines of “a loop with serial execution and whose index variable is a construct entity”.   Call it an “iterative DO” for a catchy name.
2.	Specifications at the semantic level.  This is where we’d say that there is only one index variable per “iterative DO”.
3.	Syntax.  This is where we say stuff about commas and colons, whether we use the DO keyword, whether the type-spec comes before the DO keyword or after it, and whether a comma should be required between the DO and type-spec, etc.
4.	Edits.  We do not start thinking about this *at all* at this point.  We’re not making edits to the standard, we’re coming up with additional technical suggestions for the US member body to send to WG5.  WG5 will be making the decision about whether to do item (1), and if it does so decide, may also decide none/some/much/all of item (2).  Item (3) is traditionally left to J3 to finalise *after* the preceding are settled: though properly fleshed-out proposals are hearly always accomplished by “illustrative syntax”, that’s more as a discussion aid than a decision point at the WG5 level.

 

Last meeting, JoR did not think the Requirements (or Use cases) were compelling.  Looking at the paper, it does itself no favours whatsoever by talking about syntax first, then a bit about specs, no requirements that I can see at all, and contemptuously dismisses our procedure of needing use cases.

 

If 18-242 were presented as a “draft proposal” to me, I would give it 2/10 (1 for the idea, +1 for effort).  It makes no serious attempt to follow our procedures; our procedures are there for good reason.  That means that this paper is a non-starter full stop.

 

A new paper needs to be written, and needs to have the form:

1.	Requirements
2.	Use cases
3.	Proposed Specifications
4.	Illustrative Syntax

and if this were to reach plenary, we would in the first instance be voting on the Requirements (and maybe the Specifications if they’re well enough written and reach consensus) and definitely not the Syntax.  If the Requirements are accepted, work should then proceed to settle on the Specs if they need further work, and after that, the Syntax.

 

I encourage Van, in collaboration with anyone else who supports the idea and has some time available, to write this new paper.  Sadly, although I’m sure I’d enjoy helping to write it, I do not think I have the time and energy available to do so.

 

Cheers,

-- 

..............Malcolm Cohen, NAG Oxford/Tokyo.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20181205/b52dd871/attachment.html>