From JLS@liverpool.ac.uk Fri Dec 4 17:34:14 1992 Received: from vm.uni-c.dk by dkuug.dk with SMTP id AA09781 (5.65c8/IDA-1.4.4j for ); Fri, 4 Dec 1992 18:41:43 +0100 Received: from vm.uni-c.dk by vm.uni-c.dk (IBM VM SMTP V2R2) with BSMTP id 1314; Fri, 04 Dec 92 18:43:06 DNT Received: from UKACRL.BITNET by vm.uni-c.dk (Mailer R2.07) with BSMTP id 5616; Fri, 04 Dec 92 18:43:06 DNT Received: from RL.IB by UKACRL.BITNET (Mailer R2.07) with BSMTP id 8164; Fri, 04 Dec 92 17:41:06 GMT Received: from RL.IB by UK.AC.RL.IB (Mailer R2.07) with BSMTP id 3929; Fri, 04 Dec 92 17:37:08 GMT Via: UK.AC.LIV.MAIL; 4 DEC 92 17:35:18 GMT Received: from ibm.liverpool.ac.uk by mailhub.liverpool.ac.uk via JANET with NIFTP (PP) id <21490-0@mailhub.liverpool.ac.uk>; Fri, 4 Dec 1992 17:35:20 +0000 Received: from UK.AC.LIVERPOOL by MAILER(4.4.t); 4 Dec 1992 17:35:34 GMT Date: Fri, 04 Dec 92 17:34:14 GMT From: Lawrie Schonfelder Subject: Re: (SC22WG5.264) S20/71 To: John Reid , SC22/WG5 members In-Reply-To: Your message of Tue, 1 Dec 1992 10:32:31 +0100 Message-Id: <"mailhub.li.493:04.11.92.17.35.21"@liverpool.ac.uk> X-Charset: ASCII X-Char-Esc: 29 On Tue, 1 Dec 1992 10:32:31 +0100 John Reid (jkr@UK.AC.RUTHERFORD.DIRECTORY) said: >Here is my oinion on this draft response. What do others think? > > Regards, > John. > I strongly agree with John on this. Lawrie > >I am strongly opposed to S20/71. Edit 4 (deleting the last >two sentences of 5.5.2.5) represents a change to the language >definition. These sentences were not put in by accident. A fundamental >property of modules is that an object in a module is defined once only. >The intention of the sentences is to say that if you are accessing >variables in a common block, you must not also redeclare that common >block. For example, the current non-standard practice of placing the >common block in a file and including it can be replaced by placing the >common block in a module and using it. If we allow the common block to >be redeclared in a scoping unit that accesses the module, we get an >inconsistency with the interpretation of an include. > The standard treats host association differently. Here any >object of the host, including any in a common block, may be >inherited provided no entity of that name is declared in the child. > Edits 1 to 3 add clarity but do not resolve an ambiguity. I >therefore propose either > (i) delete the end of the answer from 'One of these cases' and > delete all the edits; or > (ii) delete the sentence from 'One of these cases. ..' and the clause > 'and eliminate the ineffective restriction in 5.5.2.5'; > delete edit 4; and change 'USE' to 'use' in edits 2 and 3. > >