From vsnyder@math.Jpl.Nasa.Gov  Fri Jan 24 22:49:37 1997
Received: from eis-net-001.jpl.nasa.gov (eis-net-001.jpl.nasa.gov [137.78.57.19]) by dkuug.dk (8.6.12/8.6.12) with ESMTP id WAA20083 for <sc22wg5@dkuug.dk>; Fri, 24 Jan 1997 22:49:16 +0100
Received: from math.Jpl.Nasa.Gov (math.jpl.nasa.gov [137.78.227.106]) by eis-net-001.jpl.nasa.gov (8.7.5/8.7.3) with ESMTP id NAA16713 for <sc22wg5@dkuug.dk>; Fri, 24 Jan 1997 13:48:58 -0800 (PST)
Message-Id: <199701242148.NAA16713@eis-net-001.jpl.nasa.gov>
Received: by math.Jpl.Nasa.Gov
	(1.37.109.15/16.2) id AA061932460; Fri, 24 Jan 1997 13:47:40 -0800
From: Van Snyder <vsnyder@math.Jpl.Nasa.Gov>
Subject: Followup on "Comments on N1238"
To: sc22wg5@dkuug.dk
Date: Fri, 24 Jan 1997 13:47:39 PST
Reply-To: <vsnyder@math.Jpl.Nasa.Gov>
X-Mailer: Elm [revision: 109.14]

I've just read the piece I published on N1238, and I've already noticed
there are at least two areas where it's unclear.

First, under Section 1.1.8, I remark "intrinsic IF(..."
This should be "intrinsic _function_ IF(..."

By the way, I think the MERGE instrinsic function actually does
this, but who would think to look for this functionality there?

Second, I remark at the beginning that it's good to design features
of the language to increase the possibility that program authors
can write programs without using clumsy circumlocutions that obscure
their intent.

I had planned to enlarge on this in connection with Part III, data-E4,
wherein appears the remark "In strict object oriented programming one
would always access derived type components via an interface" and then
I forgot to do so.

Since Parnas's paper "On the criteria for decomposing programs into
modules," schools have taught that one should never write "a = b".
Instead, one should invent a subroutine with a cryptic name, and write
  CALL Value(a, b)
(A more careful author might choose Set_Value or Update or New_Value.)
Does this do a=b, or b=a, or something else?  If a program is being
written by a team, every member of the team must keep in mind which way
this goes.  Even worse, the next poor schmo who works on the program
(after the authors' contracts have expired), needs to learn this
(probably by looking at code instead of documentation), and keep it in
mind.  It would be clearer to use
  a = b
That's why it's fortunate Fortran allows INTERFACE(=).  But if one
writes a "class" and follows the discipline "...one would always access
derived type components via an interface" I don't see how to overload
intrinsic assignment to provide that interface.

So I've advocated an alternative: syntactic uniformity, and accessors.

See remarks at http://gyre.jpl.nasa.gov/~vsnyder/fortran/uniform.html,
and in X3J3 97-114.

Best regards to all,
Van Snyder