Subject: subset opinion request

From: [email-masked] (Mary E Zosel)
Date: Tue, 1 Sep 92 20:44:53 -0700

F90 group:
in the list of things we are proposing to add to the subset 
language, should we include recursive procedures???

Can an argument be made that in redesigning algorithms for
performance that recursive algorithms are sometimes wanted?

Do we anticipate any HPFsubset implementations that will not be
stack-based in some way --- and hence have difficulty with
implementation of recursive procedures???

Currently, this will NOT be on the list to propose to include unless I
hear back from some subgroup members who support it.
  -mary-

---

From: Maureen Hoffert <[email-masked]>
Date: Wed, 2 Sep 92 09:28:52 -0600

Hello,

Here are some general comments and suggestions on the F90 subset and the
current F90 sections of the draft as well as comments on your latest
proposals:

- I agree that recursion is a key feature that most implementations
support on current architectures, however, I think they do not support
the Fortran 90 form with the accompanying RECURSIVE and RESULT keyword
and functionality.  I would ask for guidance from the general committee.
I would be willing to support this either way.

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?

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.)

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.

In the current draft document, in section 8.4, the HPF directives used
do not have the correct syntax.  (They are missing the $ following HPF.)

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.

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.

In the current draft, the statement "object-oriented DATA statement"
is not clear to me what it is referring to?

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.

In section 9.2, p.  83 of the draft, the list of attribute statements
should include:  ALLOCATABLE, EXTERNAL, INTRINSIC, DIMENSION, DATA, and
IMPLICIT in order to be complete.  I imagine that the FORTRAN 77 type
statements might have been omitted because they are included in the F77
subset statement.  But I suggest that they be included in this list for
completeness.  Also for sure the following should be included
in the attribute list:  ALLOCATABLE, EXTERNAL, INTRINSIC.

Another nit, but the common style for "FORTRAN 77", has used all upper
case, while Fortran 90 has used the mixed case.

Comments on your Proposals:

On Proposal #1:

I like your proposal for interface blocks.  You might add what will
change in the draft:

Proposed change to the draft:

Add to Section 9.2 under "procedure features" change "INTERFACE blocks"
to be:

INTERFACE blocks as defined in 12.3.2.1 without a module-procedure-stmt
or a generic-spec.

I would also add your rationale as well.

On Proposal #2:
I accept your suggestions.

On Proposal #3:

In addition to your rationale,
add to 9.2 a new section entitled ". MODULE and USE statements"

Modules as defined in 11.3, R1104, but does not include the
module-subprogram-part.

Module references as defined in 11.3.1 and 11.3.2, R1107, but
only includes the syntax and semantics for USE module-name. Note
that this excludes the rename-list, and the ONLY qualifier on the
use-stmt.

On Proposal #4:

I suggest that you not use the term object oriented declarations since
this is not common terminology and could be misleading since people
in the Fortran world are still just becoming familiar with object
oriented concepts.  

I would suggest that you change your wording for Proposal #4 to read:

Proposal #4: Add Fortran 90 Type declaration statements (5.1). 

Add the new form of Fortran 90 type declaration statements which
includes allowing attribute specifications in the type statement,
and allows data initialization in the type statements.  All attr-spec
(R503) are included except POINTER, TARGET and access-spec.

Note that in the current draft we have included the KIND selector, so we
should decide if we include it or not in this proposal.

Additional Note:

The one syntax aspect that the ALIGN, etc. directives are using is
the continuation indicator from the free form syntax.  I recommend
that we do not extend the F90 subset to include this as well, but
we might note this to the larger group, that we still will not be
completely consistent.

Regards,

Maureen