Subject: Response to your email questions

From: [email-masked] (Richard Swift)
Date: Wed, 2 Sep 92 16:55:22 -0700

Mary -
	I finally finished reading the 100+ email messages that have
	accumulated from HPFF, X3J3, etc.  over the past few weeks, 
	so here are my responses to your proposals:

	Proposal 1: Interface Blocks
		Fine by me.
	Proposal 2: New intrinsics
		Fine by me, but I wouldn't spend a lot of committee
		time arguing about it: if people generally agree, OK,
		otherwise drop it.
	Proposal 3: Modules Subset
		I don't know. We must specify how MODULE/USE works with
		respect to TEMPLATES, etc. in any case. If this would
		allow us to rid the Storage and Distribution proposals of 
		all the baggage of "aggregate storage sequences" and
		"similar TEMPLATES" and all the other strange inventions
		HPFF has devised to "support" separate compilation and
		funny storage usage, then I would enthusiastically 
		support this idea. If we simply add one more way (albeit
		the 'right' way) of doing this stuff, I am not very
		excited about whether it is in the subset or not. As it 
		stands, your proposal is technically reasonable.
	Proposal 4: Entity-oriented declarations
		Fine by me.

	Proposal 5: Recursion
		Include it; again don't make a big fuss about it. If
		people agree, fine, otherwise drop it. (Note: I only
		support the Fortran 90 forms; I oppose anything that
		is NOT Fortran 90 in this area. We need standardization.)

	Also, Maureen's comments raised a few points I'd like to comment on:

>>In the current subset definition character arrays are not included.
>>However, in the current storage and sequence proposal character arrays
>>were no longer special cased and are included.  Should we now include 
>>them in the subset description?

	Leave CHARACTER array and storage features out of the subset: 
	most implementations today do not implement them in parallel. The 
	subset is supposed to help implementors produce a product quickly:
	including these would just make it harder, and take longer, for 
	extremely little added value to users.

>>In the latest draft from ftp, assumed-size arrays are still listed as
>>not part of the subset.  Should this be assumed-shape arrays, or should
>>it remove these from that list.  (Assumed-size arrays are in FORTRAN 77.)

	The idea is that assumed-size arrays are restricted with 
	respect to distribution, so only f77 style use will work.  Leaving
	it out of the subset emphasizes this: perhaps that's good.

>>I am curious for the rationale for including INTENT and OPTIONAL
>>attributes and statements?  If these attributes are included, then this
>>is another reason why we would need to include interface blocks, and the
>>concept of explicit interfaces for them.  Explicit interfaces are
>>required if the optional or keyword arguments are used.

	INTENT can allow the compiler to optimize argument passing: it
	is very helpful when re-mapping of dummy arguments occurs.  OPTIONAL
	arguments can be useful in writing more efficient subprograms for
	the same reason: missing OPTIONAL arguments don't need to be
	re-mapped. Also, these features are simple to implement when
	you are doing INTERFACE blocks, and implementors may want to 
	design as much of this stuff at once rather than piecemeal it.

>>In the current definition of the subset on p.  83 in section 9.2 the
>>KIND selector is included.  It was unclear to me if you were now
>>intending to exclude it from the syntax in your description of the
>>type declaration syntax?  See notes below on your proposal.

	KIND of COMPLEX is the only way we can get "DOUBLE COMPLEX":
	is this important for the HPF subset?

>>In 9.3 of the draft sequence and storage association is included
>>in the list of features NOT in the subset.  I suggest that we remove
>>this from the list, or add the qualification that sequence and storage
>>association is included based on the proposal in Chapter 8.  I would
>>prefer that they not be included in the list.

	I would prefer the subset does NOT allow all the weird storage
	stuff: this will allow for simple, rapid implementations that
	may avoid all the complications as users just clean up the
	COMMON problems once and for all. Can we at least keep the
	subset simple? (I've just about given up on keeping the
	full language simple.)

>>As I commented earlier to Mary, I am in favor of SEQUENTIAL and
>>NONSEQUENTIAL so as not to overload or be confused with the current
>>SEQUENCE statement in Fortran 90.
	
	The SEQUENCE/NOSEQUENCE keywords were chosen BECAUSE they are
	the same as the SEQUENCE statement in Fortran 90. They seem
	to act exactly like the SEQUENCE statement. So if, in the future,
	you think of deleting the !HPF$ prefix, they turn into F95
	statements that mean exactly the right thing. I don't want
	another new, different keyword.

	Finally, I will be out of reach of email after Friday Sept 4,
	so if you cannot get to me before then, see you at the meeting
	next Wednesday in Dallas.
						- Rick