From J.L.Schonfelder@liverpool.ac.uk Fri May 27 17:00:08 1994 Received: from mailhub.liverpool.ac.uk (mail.liv.ac.uk) by dkuug.dk with SMTP id AA07401 (5.65c8/IDA-1.4.4j for ); Fri, 27 May 1994 17:02:11 +0200 Received: from 138.253.31.200 by mailhub.liverpool.ac.uk with SMTP (PP) id <18699-0@mailhub.liverpool.ac.uk>; Fri, 27 May 1994 16:00:09 +0100 From: "Dr.J.L.Schonfelder" Message-Id: <9405271500.AA03294@uxb.liv.ac.uk> Subject: Re: Exception Handling (fwd) To: SC22WG5@dkuug.dk (SC22/WG5 members) Date: Fri, 27 May 1994 16:00:08 +0100 (BST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 5201 X-Charset: ASCII X-Char-Esc: 29 It is a long weekend here in the UK and John has gone on holiday for a week. I cant continue this discussion off line for that time so I am distributing it more widely. I am also distributing an out line proposal by Mike Delves which I believe has a good chance of solving the problems. Dr.J.L.Schonfelder wrote > From ukfortran-request@castle.edinburgh.ac.uk Fri May 27 14:53:28 1994 > From: "Dr.J.L.Schonfelder" > Message-Id: <9405271349.AA21859@uxb.liv.ac.uk> > Subject: Re: Exception Handling > To: John Reid > Date: Fri, 27 May 1994 14:49:09 +0100 (BST) > Cc: UK Fortran Panel > In-Reply-To: <9405251638.AA29592@jkr.cc.rl.ac.uk> from "John Reid" at May 25, 94 05:38:34 pm > X-Mailer: ELM [version 2.4 PL23] > Mime-Version: 1.0 > Content-Type: text/plain; charset=US-ASCII > Content-Transfer-Encoding: 7bit > Content-Length: 3886 > Sender: ukfortran-request@castle.edinburgh.ac.uk > > John Reid wrote > > > > > > > I have been reading John's latest draft and I have some serious worries. > > > Can any of you help answer my problem. I asked John but he seems to be > > > away or something, as I have not had any reaction. > > > > I am here, but the email address jkr@directory.rl.ac.uk has been withdrawn. > > Were you using this? > yes. I will amend my alias file. > > > > > > > My problem is with the global nature of condition names and the automatic > > > signalling up the call chain looking for a handler. > > > The problem I have is with user defined conditions. Since they are global > > > the condition name is known for the whole executable program. Thus condition > > > name management appears to be an issue. > > > > True, but I believe that we can live with this. > If you and J3 can live with this can you wonder why I get so angry about > inconsistency in technical judgement. The name management problem you > are blithly prepared to live with makes the issue created by type-param > inquiry functions pale into total insignificance. For the latter there will > be an easy work round even if you were unlucky enough to hit the low > probability problem. With your problem if it hits you you have no work > round at all. > I have been determined to > > keep to the KISS principal and the have received much appreciation from > > the vendors of X3J3 because of it. > This is not KISS it is a killer. You are actually adding complexity by > introducing ad hoc language features in the name of false simplicity. > > > > > > > Can I have two procedure (possibly from different libraries) each containing > > > a condition with the same name but different meanings in the same > > > executable program? > > > > Yes, but I think it is unlikely (see below). > Sorry but I dont agree. I think it inevitable that users will use the same > name for different conditions in different procedures. It may not be > sensible but I bet "convergence_failure" or some such will be common. > Nag might be careful but all library developers will not be. We know already > that developers work as if they were the only one in the field. > How many graphics libraries have a routine called PLOT? > > > > > If not how do I manage the name clash? If I can how do I distinguish and > > > handle a signal if both conditions could be signalled in the same enable block? > > > > You would have to use a smaller block. > Not always possible without code butchering. What if the two procedures > logically occur in the same statement. > > > > > > > Finally, what would happen if one condition signalled and propagated up the > > > chain to a handler that was actually intended to handle the other condition? > > > > Of course, you would handle it. > If I knew about it I might but I might not be aware of the existance of the > interior condition until I handle it incorrectly, possibly I wont know even > then. The wrong handler may execute producing wrong results but no other > signal. > > > > > Are these real concerns or am I falling into the trap I criticise J3 for, > > > viz. of finding non-problems because of ingnorance? > > > I think exception handling is of critical importance but I am concerned that > > > this simple perhaps even simplistic approach is going to create problems. > > > > I do not see this as such a terrible problem. Nag will prefix all their > > names with Nag_, we will prefix with HSL_, etc. > I am sorry John. I believe you have now convinced me these are very real > problems. We could not allow F95 to include such scope for error and little > scope for the user correcting the problem. I think conditions should have > names with a local scope (intrinsic ones obviously are global but user > defined should be localised in effect and users should be able to rename etc. > to control the name propogation). > > -- > Dr.J.L.Schonfelder > Director, Computing Services Dept. > University of Liverpool, UK > Phone: +44(51)794 3716 > FAX : +44(51)794 3759 > email: jls@liv.ac.uk > > -- Dr.J.L.Schonfelder Director, Computing Services Dept. University of Liverpool, UK Phone: +44(51)794 3716 FAX : +44(51)794 3759 email: jls@liv.ac.uk