From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Sun Dec 22 18:10:52 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 B4E733583E6; Sun, 22 Dec 2013 18:10:52 +0100 (CET) Delivered-To: sc22wg5@open-std.org Received: from mail-pd0-f175.google.com (mail-pd0-f175.google.com [209.85.192.175]) by www.open-std.org (Postfix) with ESMTP id 38D9C358360 for ; Sun, 22 Dec 2013 18:10:52 +0100 (CET) Received: by mail-pd0-f175.google.com with SMTP id w10so4360819pde.34 for ; Sun, 22 Dec 2013 09:10:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=01zqnqX3hDTww36YZBNIDkZLqJPGyRnBiKoax/dSMVs=; b=A9O4gPqMov3PrDCavevdSLHv10BnEHUEpyHz0EMMq0wKGebzrqknNs7uoqTInDvgCZ MvI/6EUNu21gPech5hzt7R9dO0UZfm/HovZxsyBnULxtTwE9hBjSn4NTTsq8y1sQ8ToA 1k2airSQV62h1ZWRpoGPWfv5I/HqnYmaDmwDfhNbwMRC7WxwSzehHHpSDX9AWqYr6OX0 BKDajT7qIaq1auk5c6ClkHzUDiGfzyqX0ZcWo8kID0KU8y0gw+t88WA1qHdq9Up6sPDj Xi273Qm0WyMWGkqjz51zbM6adAPlUqniOP4OLvk3+D4lLYglnZ+c7xCCdfglSi1KVWCp L4lg== X-Gm-Message-State: ALoCoQmpYk5fvEPPz5N8/iMiQ3XE7qwJjFGg3wKA+UcNjF3AtfyIMHwYhjnVT6vTozCgYrNkSX0n X-Received: by 10.66.149.37 with SMTP id tx5mr20958645pab.81.1387732250595; Sun, 22 Dec 2013 09:10:50 -0800 (PST) Received: from [10.0.1.7] (c-50-136-220-5.hsd1.ca.comcast.net. [50.136.220.5]) by mx.google.com with ESMTPSA id vf7sm28535133pbc.5.2013.12.22.09.10.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 22 Dec 2013 09:10:49 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: (j3.2006) (SC22WG5.5164) [ukfortran] [ Draft corrigendum 3] From: Damian Rouson In-Reply-To: <20131222170003.2097B3583E4@www.open-std.org> Date: Sun, 22 Dec 2013 09:10:48 -0800 Cc: sc22wg5 Content-Transfer-Encoding: quoted-printable Message-Id: <6A07F7B9-E346-4E98-8C59-D9991721B065@rouson.net> 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> <20131222170003.2097B3583E4@www.open-std.org> To: fortran standards email list for J3 X-Mailer: Apple Mail (2.1827) Sender: owner-sc22wg5@open-std.org Precedence: bulk Hi Tom, I use the same style. I first discovered this style in Ed Akin=92s book = Object-Oriented Programming via Fortran 90/95 (Cambridge University = Press, 2003) so the style has at least a decade-long history and many = adherents. Damian On Dec 22, 2013, at 8:30 AM, Tom Clune wrote: > 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. >=20 > 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. >=20 > Do others use this? Does anyone have an interesting rebuttal? = Always looking to improve my style =85 >=20 > Cheers, >=20 > - Tom >=20 >=20 > On Dec 22, 2013, at 4:54 AM, N.M. Maclaren wrote: >=20 >> 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 >=20 > 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 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > J3 mailing list > J3@mailman.j3-fortran.org > http://mailman.j3-fortran.org/mailman/listinfo/j3