From aurelio.pollicini@cen.jrc.it Tue Oct  5 15:42:49 1993
Received: from chx400.switch.ch by dkuug.dk with SMTP id AA03441
  (5.65c8/IDA-1.4.4j for <sc22wg5@dkuug.dk>); Tue, 5 Oct 1993 14:42:51 +0100
Received: from jrc.jrc.it by chx400.switch.ch with SMTP (PP) 
          id <14824-0@chx400.switch.ch>; Tue, 5 Oct 1993 14:43:34 +0100
Received: from sad.isei.jrc.it (uranus) by cen.jrc.it;
          Tue, 5 Oct 93 14:40:10 +0100
From: Aurelio Pollicini <aurelio.pollicini@cen.jrc.it>
Date: Tue, 5 Oct 93 14:42:49 +0100
Message-Id: <5890.9310051342@sad.isei.jrc.it>
To: dtm@castle.ed.ac.uk
Subject: Comments on BSI proposal
Cc: sc22wg5@dkuug.dk
X-Charset: ASCII
X-Char-Esc: 29

To:    David Muxworthy (editor of proposal)
fr:    Aurelio Pollicini
sj:    Comments to "Language Evolution Proposals"
dt:    October 5th, 1993

Dear David,

my personal opinion on this subject is known, thus it is not surprising
that I spend a couple of words in support of the proposal. In particular,
I appreciate the clarity of the document and the lucid rationale.

Also, everyboy knows that I believe that \bf{all features related to
storage association} should be moved to the obsolescent list and I'm 
ready to support such an opinion if there is a way to promote consensus.

I consider the BSI proposal as a positive and realistic step towards the
culture of \it{... shake off the dust of your feet} - Matt. X, 14.

As such, I fully support it.
Just few comments are appended concerning section 6.

Regards,
           Aurelio
.....................................................................

Ref. Sec 6.1

I have a specific point about the action proposed, however, I address 
the general context first, so that the specific consideration is seen
in the light of its actual motivation.

a) my opinion on the intended purpose of obsolescence

   The pragmatic reader of the standard may see the obsolescent list just
   as the threat of a potential loss; I associate to the concept of
   obsolescence the more noble purpose of education.
   The obsolescence flag is the approach followed by the standard for
   prompting users about some features being increasingly unadvisable
   in the environments offered by today technology.
   \bf{Discourage actual use in new code} is (and should be considered)
   the primary goal of the obsolescence flag.

b) my strong belief in the role of appropriate tools

   In any context, evolution is successful only if supported by
   effective tools.
   The statement \{It is a simple matter for a tool to convert 
   from ... to ... .} (ref last sentence of Sec. 4.6) has a relevance
   much wider than the context in which is used in the BSI proposal.
   The concept it expresses is worth applying to all points of the
   proposal as well as to what the proposal does not mention explicitly
   (ref Sec. 6.2).

c) my evolutionary algorithm

   Not to frighten the community of users, repeatedly bothered by
   migration/conversion of code, I try to put in unambiguous logics
   the course of my mind:

      IDENTIFY   unadvisable-feature
      DISCOURAGE use of unadvisable-feature 
      SUPPORT    development of transformation-tool
      DO
          PROMOTE use of transformation-tool
          IF  level-of-use  below  significance
            THEN  ! and only then
                   MOVE  unadvisable-feature  to deleted-list
                   EXIT
          ENDIF
       ENDDO

Thus set my viewpoint, I object to the last sentence of Sec. 6.1, namely,
\it{... these items ... would not be acceptable to the user community ...}.

What is not acceptable \it{... at this time.} ?

My answer is that it is not acceptable to delete those items at this time,
but it is perfectly acceptable to tell the community they are (1) obsolescent
for recognized reasons and (2) deemed to be deleted at a future term (when, and
only when, the requirements for deletion are fulfilled).

Ignoring the educational aspect of obsolescence and, consequently, not
including the features referred to in Sec 6.1 into the set of obsolescent
features at this time, is loosing the opportunity of slowing down the rate
of unreliable new code being developed, with a consequent impact both
on credibility of Fortran and on the reputation of Fortran compilers.

Of course, the consideration of the previous paragraph is applicable to
any unadvisable-feature identified at this time or any future time.

...............................................................end-comments