From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Sun Dec 22 18:00:03 2013 Return-Path: X-Original-To: sc22wg5-dom8 Delivered-To: sc22wg5-dom8@www.open-std.org Received: by www.open-std.org (Postfix, from userid 521) id 012B83583E1; Sun, 22 Dec 2013 18:00:02 +0100 (CET) Delivered-To: sc22wg5@open-std.org X-Greylist: delayed 1749 seconds by postgrey-1.34 at www5.open-std.org; Sun, 22 Dec 2013 18:00:02 CET Received: from ndmsnpf01.ndc.nasa.gov (ndmsnpf01.ndc.nasa.gov [198.117.0.121]) by www.open-std.org (Postfix) with ESMTP id 402753583DE for ; Sun, 22 Dec 2013 18:00:01 +0100 (CET) Received: from ndmsppt102.ndc.nasa.gov (ndmsppt102.ndc.nasa.gov [198.117.0.67]) by ndmsnpf01.ndc.nasa.gov (Postfix) with ESMTP id 73E06260025; Sun, 22 Dec 2013 10:30:54 -0600 (CST) Received: from NDMSCHT105.ndc.nasa.gov (ndmscht105-pub.ndc.nasa.gov [198.117.0.205]) by ndmsppt102.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id rBMGUoKr015405; Sun, 22 Dec 2013 10:30:50 -0600 Received: from [10.175.207.189] (70.192.221.146) by smtp02.ndc.nasa.gov (198.117.0.205) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 22 Dec 2013 10:30:49 -0600 Content-Type: multipart/alternative; boundary="Apple-Mail=_564A864F-3137-4CC3-9980-F093B3576D01" MIME-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: (j3.2006) (SC22WG5.5162) [ukfortran] [ Draft corrigendum 3] From: Tom Clune In-Reply-To: <20131222095446.4ADE13583AF@www.open-std.org> Date: Sun, 22 Dec 2013 11:30:48 -0500 CC: sc22wg5 Message-ID: <57DC3DB3-2873-4EA2-85BE-AD1F87686F1F@nasa.gov> References: <20131126013542.D88A93582CC@www.open-std.org> <20131220171849.090F03582F4@www.open-std.org> <20131222004843.861D635835A@www.open-std.org> <20131222095446.4ADE13583AF@www.open-std.org> To: fortran standards email list for J3 X-Mailer: Apple Mail (2.1510) X-Originating-IP: [70.192.221.146] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87,1.0.14,0.0.0000 definitions=2013-12-22_01:2013-12-20,2013-12-22,1970-01-01 signatures=0 Sender: owner-sc22wg5@open-std.org Precedence: bulk --Apple-Mail=_564A864F-3137-4CC3-9980-F093B3576D01 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="windows-1252" Perhaps getting a bit off topic, but there _is_ one case of separating = the attributes that I actually use routinely and regularly advise others = to do so. Namely, the PUBLIC attribute. I find that a nice module = style is to have a default PRIVATE statement followed by a list of the = public entities. Detailed specifications are further into the text. Once a module has a number of nontrivial declarations (e.g. derived = types), then the PUBLIC attribute an get a bit buried. I want users of = my modules to be able to tell at a glance which facilities are provided. = Of course this assumes that all of the public entities have names that = are laden with clear intent. As with many good practices, they rely and = support other good practices. Do others use this? Does anyone have an interesting rebuttal? Always = looking to improve my style =85 Cheers, - Tom On Dec 22, 2013, at 4:54 AM, N.M. Maclaren wrote: > On Dec 22 2013, Malcolm Cohen wrote: >>=20 >> I (and others) disagree with your assertion that >> REAL x(*) >> PARAMETER(x =3D [ 1,2,3,4,5 ]) is unreasonable and should never be=20= >> allowed. Disallowing this would break one of our basic design rules = for=20 >> the BNF of declarations, which is that one can specify attributes=20 >> independently. Yes it is a smaller edit to the standard, and would = not=20 >> remove significant functionality ... but then deleting the PARAMETER=20= >> statement entirely would not remove significant functionality! >=20 > As someone who was not involved, I regrettably agree - though I think > that Bill is right that such code IS unreasonable. Introducing > gratuitous restrictions should be considered only when they prevent > actual, fairly common, mistakes. I can't see one that this blocks. >=20 > As someone who teaches both Fortran and C++, I really appreciate the > consistency and relatively tiny number of 'gotchas' of Fortran. > Fortran syntax may be verbose and horrible, but it is clean and > consistent (remember that I prefer Algol 68!) >=20 > I don't teach setting attributes separately but, if someone asks, I > can simply say that I don't advise it but it can be done. That's it. > A couple of minutes, and it's covered. >=20 >=20 > Regards, > Nick Maclaren. >=20 > _______________________________________________ > J3 mailing list > J3@mailman.j3-fortran.org > http://mailman.j3-fortran.org/mailman/listinfo/j3 Thomas Clune, Ph. D. = Chief, Software Systems Support Office Code 610.3 NASA GSFC = 301-286-4635 MS 610.8 B33-C128 = Greenbelt, MD 20771 --Apple-Mail=_564A864F-3137-4CC3-9980-F093B3576D01 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="windows-1252" nmm1@cam.ac.uk> = wrote:
On Dec 22 2013, Malcolm Cohen wrote:

I (and others) disagree with your assertion that
=  REAL x(*)
 PARAMETER(x =3D [ 1,2,3,4,5 ]) is unreasonable = and should never be
allowed. Disallowing this would break one of our = basic design rules for
the BNF of declarations, which is that one = can specify attributes
independently. Yes it is a smaller edit to = the standard, and would not
remove significant functionality ... but = then deleting the PARAMETER
statement entirely would not remove = significant functionality!

As someone who was not = involved, I regrettably agree - though I think
that Bill is right = that such code IS unreasonable.  Introducing
gratuitous = restrictions should be considered only when they prevent
actual, = fairly common, mistakes.  I can't see one that this = blocks.

As someone who teaches both Fortran and C++, I really = appreciate the
consistency and relatively tiny number of 'gotchas' of = Fortran.
Fortran syntax may be verbose and horrible, but it is clean = and
consistent (remember that I prefer Algol 68!)

I don't = teach setting attributes separately but, if someone asks, I
can = simply say that I don't advise it but it can be done.  That's = it.
A couple of minutes, and it's = covered.


Regards,
Nick = Maclaren.

_______________________________________________
J3 = mailing list
J3@mailman.j3-fortran.orghttp://mailman.j3-fortran.org/mailman/listinfo/j3
<= br>
Thomas Clune, Ph. = D.  = <Thomas.L.Clune@nasa.gov>
Chief, Software Systems Support Office = Code 610.3
NASA GSFC = 301-286-4635
MS 610.8 B33-C128 = = <http://ssso.gsfc.nasa.gov>
=
Greenbelt, MD = 20771





= --Apple-Mail=_564A864F-3137-4CC3-9980-F093B3576D01--