From drlevine@apollo.hp.com Thu Nov 2 23:06:47 1995 Received: from amway.ch.apollo.hp.com (daemon@amway.ch.apollo.hp.com [15.254.24.2]) by dkuug.dk (8.6.12/8.6.12) with ESMTP id XAA10191 for ; Thu, 2 Nov 1995 23:06:42 +0100 From: drlevine@apollo.hp.com Message-Id: <199511022206.XAA10191@dkuug.dk> Received: from hillside.ch.apollo.hp.com by amway.ch.apollo.hp.com id Thu, 2 Nov 1995 17:06:22 -0500 Received: by hillside.ch.apollo.hp.com id ; Thu, 2 Nov 1995 17:06:21 -0500 Date: Thu, 2 Nov 95 17:06:20 EST Subject: Re: (SC22WG5.932) USE statements, continuing confusions To: "Janice C. Shepherd ((914) 784-6313)" Cc: sc22wg5@dkuug.dk In-Reply-To: "Janice C. Shepherd ((914) 784-6313)" , Thu, 2 Nov 95 15:07:31 EST Janice writes: > One of the items that needs to be discussed at the meeting next week > (US required comment number 20) has to do with the statement in the standard: > "If one of the USE statements is without an ONLY qualifier, all > public entities in the module are accessible and the > and are interpreted as a single concatenated > ." > F95 reference: 185:34-36 section 11.3.2 > > The issue is whether the non-rename items from the ONLY qualified > USE statements are included in the concatenated . My humble opinion: This part of the Standard is simply IN ERROR, and should be fixed (for Fortran 95, at least!). -> it should not be possible to list the same name twice in USE statements for a given module; -> it should not be possible to list a name both with and without rename; -> it should not be possible to list the same module in both "only" and non-"only" form. Fixing it will close this area of contention, and simplify the language. ---- I know that this was all permitted by Fortran 90. However, the experience of many years seems to indicate that: - we still don't understand how it's supposed to work; - existing implementations DIFFER It's also not clear that this capability adds anything in the way of useful functionality. -> from all of which I draw the conclusion that making this change would be unlikely to affect lots of users! ---- This mechanism is not consistent with what's done elsewhere in the Standard, where (by and large) we've been careful to AVOID the possibility of multiple specifications. - attributes for a variable cannot be specified multiple times - an internal procedure cannot have an interface block What rationale mediates allowing duplication in this case? David Levine HP Languages - Chelmsford -------