[J3] 18-156

[Van Snyder]

On Tue, 2018-02-27 at 19:43 +0000, Bill Long via J3 wrote:
> Just to clarify, what Van is calling a ?TS? has nothing to do with an
> ISO Technical Specification, which is also called a TS.  An ISO TS
> requires WG5 approval,  SC22 approval, and assignment of an official
> editor by ISO. What Van is talking about is a document he wrote on his
> own that had the visual appearance of a TS, but was not in any way
> approved or official. 

When it was chopped of the priority list at meeting 168, I was urged to
pose it as a TR.  So I did.  Now people are asking "Why do you want to
do what to do what we told you to do?"

I don't call it a TS.  I intentionally use "draft" and "TS proposal" in
descriptions.  I never pretended it was a published TS, and implying I
did is a dishonest exaggeration.

168 was the same meeting where extensible modules were chopped of the
priority list.  I was urged to propose a TR, but restricted to what are
now submodules.  Steve's survey had a request to extend the part of a
module accessible by use association, which was part of my original
proposal.  BTW, these are what Ada calls "private child units" and
"public child units."  I don't know java or python, but just guessing
based upon naming schemes with multiple identifiers separated by dots,
it seems these languages have similar features.  Several standards know
how to describe this, and several language processors know how to do it.

> Tom makes a relevant point about vendors.  One of the purposes of a TS
> is to allow vendors a head start on implementing a feature.

I don't know how many vendors plan to implement the C TS that explicit
says it might never be implemented.  I don't remember the topic.  WG9
approved it as a TS work item anyway, and ISO published it.  If users
see it, they might ask vendors for it, and then vendors might do it.
Maybe that's why vendors don't want the units proposal published as a
non-binding TS.

> Vendors have uniformly made it clear that there was no interest in
> implementing his pet project.

I think you mean "is" not "was."

Maybe all the users who come to J3 and WG5 meetings should just butt
out.  We've spent the last two revisions on standardizing Cray
extensions, including working on two TS's that were supposed to be done
offline with independent schedules, and spent precious little time on
what users are asking for.

> One of the various reasons why this has never gotten any approval from
> the committee. 

What "various" reasons?  As far as I have been told, it's the *ONLY*
reason it has not been approved for publication as a non-binding TS that
would have no official or binding effect on any vendor.  And "never
gotten approval" is a bit of a distortion.  It was favorably received in
2002-04.  It wasn't (and never has been) rejected on technical grounds.
It was pushed off the priority list at 168.  Then I was urged to pose it
(and submodules) as a TR.  There were discussions of the technical
merits and details at the first Delft meeting, where I was urged to
continue development of it as a TS.  I was not told to drop it until
London, where an explanation for the reasons not to publish was promised
but was not forthcoming.

By looking at the preference votes in column D of 04-302.xls, one can
see that it was about as favorably received as C_SIZEOF and contiguous
pointers, and way ahead of two "more interop" proposals, indeterminate
(assumed) rank, unsigned integers, internal procedures as actual
arguments, bit data type, declarations within constructs, exit from any
labeled construct, new intents, ... all stuff that was either done or is
now proposed and being seriously considered.  So pretending it was a
dead duck from the get-go is just false.