From maine@altair.dfrc.nasa.gov Fri Nov 3 00:02:33 1995 Received: from altair.dfrc.nasa.gov (altair.dfrc.nasa.gov [130.134.34.72]) by dkuug.dk (8.6.12/8.6.12) with SMTP id AAA11657 for ; Fri, 3 Nov 1995 00:02:30 +0100 Received: by altair.dfrc.nasa.gov (5.0/SMI-SVR4) id AA06451; Thu, 2 Nov 1995 15:04:31 +0800 Date: Thu, 2 Nov 1995 15:04:31 +0800 Message-Id: <9511022304.AA06451@altair.dfrc.nasa.gov> From: Richard Maine To: sc22wg5@dkuug.dk In-Reply-To: <199511022206.XAA10205@dkuug.dk> (drlevine@apollo.hp.com) Subject: Re: (SC22WG5.933) USE statements, continuing confusions content-length: 1438 Dave says: > 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! One clear functionality is the ability to give two local names to a single name imported from a module. I don't recall whether I happen to use that, but it is certainly a functionality that you'd loose. Also, there is one thing in this general area that is used *A LOT*. I personally use it extensively, and I think many other people that use modules also do. Namely: Let something be defined in module A; perhaps a derived type, though it doesn't really matter what. Then let module B USE module A and also declare some other things; perhaps it declares some variables of the derived type. Module B also "exports" the type that it "imported" from module A. Now the main program USEs both module A and module B - no complicated renames or onlys, just simple USE statements. This imports the derived type name twice, once directly from A and once indirectly from B. I won't try to present the argument why I think this is a reasonable way to do things - I'll just point out that it is currently a legal way and one that is widely used. I guarantee that you will break lots of code if you make this illegal; it would certainly break all of my f90 code. -- Richard Maine maine@altair.dfrc.nasa.gov