From J.L.Schonfelder@liverpool.ac.uk Tue Jun 27 15:30:27 1995 Received: from mailhub.liverpool.ac.uk (mail.liv.ac.uk) by dkuug.dk with SMTP id AA16035 (5.65c8/IDA-1.4.4j for ); Tue, 27 Jun 1995 15:30:27 +0200 Received: from pop.liv.ac.uk by mail.liv.ac.uk with SMTP (PP); Tue, 27 Jun 1995 14:29:08 +0100 Received: from jlspc.liv.ac.uk (jlspc.liv.ac.uk [138.253.102.118]) by pop.liv.ac.uk (8.6.12/8.6.6-ajt-2) with SMTP id OAA18029 for ; Tue, 27 Jun 1995 14:23:38 +0100 Date: Tue, 27 Jun 1995 14:28:21 OBS From: Lawrie Schonfelder Subject: Re: (SC22WG5.827) defect item 127 To: sc22wg5@dkuug.dk Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Charset: ASCII X-Char-Esc: 29 On Fri, 23 Jun 95 10:51:02 EDT Janice C. Shepherd (8-784-6313) wrote: > Lawrie observes > - that a module is a global entity > - that context is sufficient to differentiate between what is > intended to be a module name and a local object of that name. > > The same argument can be made for the name of a PROGRAM. So if > we are going to add another exception to the rule that a global name > cannot be the same name as a local name for modules, then we should > also make an exception for PROGRAM names. But I'm not sure that this > is the right direction for us to be going. As Janice rightly points out the current rules about names, classes and when and where names can refer to items in more than one class are riddled with inconsistencies and restrictions for which there are no technical justifications. The module name issue is another one. I am firmly of the opinion that we should clean up the class rules in such a way as disallow duplicate use of names only where there is a genuine risk of ambiguity. The current mess is both confusing difficult to teach and hard to use. There may be a very large set of possible names combiatorially but the set that is meaningful in any context is relatively small (how many routines called PLOT are there???). Anything that reduces the possibility that a user will create an illegal program because of a clash of names that technically is not ambiguous and is only illegal by standards committee dictat is unfriendly. I do not believe users are all that likely to create legal but wrong programs because of the existance of names distinguished by context. We already have this capability anyway but inconsistently. Also human beings are very adept at distinguishing by context. WE do it all the time in using any natural language, particularly English which more often than most languages determines parts of speech (syntax) by context. Computers have more difficulty with handling context sensitivity but in these enlightened times even that is not too big a problem where not real ambiguity exists. Too try to enforce a one name one entity policy, when it is already for good reasons broken, is unhelpful and ever so slightly perverse it seems to me. Hence my opposition to interpretation 127 and to other proposals of this ilk. > > While the context is currently sufficient to distinguish between > a module name and a local name, are we sure that some future feature > added to the language might not best be handled by syntax that > clouds that distinction? For example, there is currently a rule > that if two module references cause two different objects with the > same name to be accessible by use association then neither object > must be referenced. A possible way of relaxing that rule is by allowing > syntax such as %, but that syntax would be > precluded if we relaxed the rules now to allow module names and local > names to be the same. not true! This construct only becomes ambiguous if a structure called module-name exists with a component called use-name. I would oppose this syntax for this purpose anyway. One sure source of linguistic problems and use confusion is to have one syntactic construction that has very different semantics. It was precisely that we did not want to get into this syntactic/semantic morass that the renaming capability of the USE statement was introduced. -- Dr.J.L.Schonfelder Director, Computing Services Dept. The University of Liverpool, UK e-mail J.L.Schonfelder@liv.ac.uk phone: +44(151)794-3716 fax: +44(151)794-3759