J3/99-170

Date:        7 Jun 99
To:          J3
From:        R. Maine
Subject:     Editor's edits


The following edits are proposed by the editor.

  [369:40] "or" to obs font.

Avoid implication that advance="YES" means non-advancing.

  [202:33] "nonadvancing" -> "advancing".  Then interchange the
  next 2 sentences.  (Make the "yes" one first).

Fix multiple problems by simplification.  This statement failed
to include stream I/O, where ADVANCE= is allowed.  On the other
hand, it failed to exclude cases where ADVANCE is disallowed.
It seems simplest to just say what we mean, which is that
this applies to any statement where ADVANCE= is allowed,
rather than trying to duplicate.

  [202:35]  "formatted sequential input/output statement" ->
  "an input/output statement that allows the specifier"

In response to some of the comments in 99-136:

  [40:33] Index "direct component"
  [41:8] Index "ultimate component"

  [46:33] "never allowed to be of a subsequently" ->
     "always required to be of a previously"

  [50:12] "a" -> "an"

  [52:34] "instead of" -> ";the accessibility of a data component
    is not affected by a PRIVATE statement in"

  [61:4] Force some space before the "is"
  (though it would be nice if the term were slightly shorter)

The following responses to comments in 99-136 do not have
edits proposed in this paper:

  The request to index every bnf syntax term is possibly a good
  idea, but may be more work than the editor has time for.  It
  would be lovely if someone else would pitch in to do some
  indexing work (as happened with f95).

  I believe that the reason for not defining the term "entity"
  was that it is used in the English sense without needing a
  specialized definition.  If we did define it, the definition
  would probably be broad enough to reaad a bit strangely.  My
  understanding is that the term "entity" is used to mean pretty
  much "anything."  The "definition" in the glossary is just a
  list of the various kinds of things that happen to be referred
  to in the document.  It isn't really very descriptive.  I'm
  not realy sure that even the glossary entry is very useful,
  and I suspect that a normative definition might actually be
  harmful (by getting wrong).  The term "entity" is used as
  a catchall for things that do not necessarily fall in one of
  the more narrowly defined terms.  We don't want to end up
  ever saying that something isn't an entity and therefore needs
  to be referred to be some other terminology.

  [41:8] "Ultimate componentness" was certainly envisioned as static.
  The editor is not prepared to review this matter - that would
  have to be someone else.

  [42:2-3]  I generally prefer to express things more in terms of
  semantics and less in terms of syntax.  This moves in the opposite
  direction.  Although I don't strongly object to the change, I
  don't think I'll advocate for it either.

  [45:17] The "itself" is intended to avoid possible confusion
  with the type that the type parameter is a parameter of (if you
  can follow that confusing statement).  Without the "itself"
  it would be easy to misread the statement as saying that
  only integers have type parameters.  The "itself" is certainly
  not necessary, but I think it helps avoid such misreading.

  [52:23-26] I think the original was more clear.  The proposed
  version talks only about what happens when you do not explicitly
  declare the access-spec.  I find it clearer to first make the
  relatively simpler statement about what the explicitly declared
  case is about before going into what the default is.