From j.l.schonfelder@liverpool.ac.uk Wed Jul 1 14:17:26 1998 Received: from pcmail.liv.ac.uk (exim@pcmail.liv.ac.uk [138.253.252.13]) by dkuug.dk (8.6.12/8.6.12) with SMTP id OAA12061 for ; Wed, 1 Jul 1998 14:17:24 +0200 Received: from jlspcnt.liv.ac.uk [138.253.102.118] by pcmail.liv.ac.uk with smtp (Exim 1.73 #2) id 0yrLp9-0006us-00; Wed, 1 Jul 1998 13:17:19 +0100 From: Lawrie Schonfelder Reply-To: j.l.schonfelder@liverpool.ac.uk To: John Reid Cc: SC22WG5@dkuug.dk Subject: Re: (SC22WG5.1525) ISO/IEC 1539-2: Varying Length Character Strings In-Reply-To: <199806291412.QAA16254@dkuug.dk> Message-ID: Date: Wed, 1 Jul 1998 13:17:18 +0100 (British Summer Time) Priority: NORMAL X-Mailer: Simeon for Win32 Version 4.1.5 Build (43) X-Authentication: IMSP MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII On Mon, 29 Jun 1998 15:12:57 +0100 (BST) John Reid wrote: > I have prepared a new draft of the revised ISO/IEC 1539-2, with the > changes agreed in Trollhatten (see N1319). Lawrie and Steve have seen > a draft and I have accommodated their comments except for the treatment > of REPEAT and LEN. It is not just these two that I am unhappy about being made elemental. The TRIM procedure is also classified intrinsically as transformational. I believe it is a BAD principle to overload a transformational intrinsic with an elemental version for a derived type. By all means make F2000 have these three intrinsics re classified as elemental and then part 2 for varying strings could reasonably follow, but I think it is a thoroughly bad idea to have overloads in the part 2 standard that classify the functions differently. > > Lawrie is opposed to our decision to make REPEAT elemental. As defined > in the standard NCOPIES must not be negative. The sample module STOPs > with a message on the default I/O unit if NCOPIES is negative. This has > to be removed if REPEAT is to be elemental. My view is that this is OK > - the philosophy of the intrinsics is that the compiler is not rwquired > to check for error conditions. As many people have indicated the sensible error behaviour for a function under a scalar call may not be sensible in an elemantal array context. A sensible way of handling overloads where there is an error condition is to try to make the behaviour the same as that for the generic intrinsic. For some of the varying string overloads this is possible. For example, ICHAR where it is undefined when called with a non-unit-length string. In this case it is simple since the overload can work by simply embedding a call to the relevant intrinsic to produce the same result. This is not possible meaning fully for repeat. If REPEAT(varstr,ncopies) is to made elemental it needs to be programmed to have a responce on negative ncopies that is meaningful, detectable post call, and that does not terminate execution. I see no way of making this the same as intrinsic repeat. I would suggest that negative ncopies is treated as if a zero ncopies had been supplied. This would in my view have been a better definition for intrinsic repeat rather than the current prohibition and undefined responce if the prohibition is breached. To make repeat elemental is a bad idea. > > Lawrie also points out that the existing REPEAT is not elemental. He > says" The intrinsic language and procedures set the basis. Extending > these to a derived type should retain as much of the characteristics of > the intrinsic as possible. If the behaviour for an extended type is > significantly different it should be provided by a different procedure > not by an overload to the intrinsic. This is just adding complexity for > the user. As a general principle I think it is bad design to have > procedures that are elemental for one overload and transformational for > another, particularly when they overload an intrinsic. pureness and > elementalness should be a characteristic of a whole generic set not > just some specific mebers of the set." > > A similar argument holds for LEN. and for TRIM. > > I would be most grateful for your opinion on this. Please comment by > the end of this week (i.e. by July 5th) or let me know that you wish to > comment, but need more time. I am not over impressed by the recommendation to make the substring manipulation procedures elemental either. There is no technical constraint as in the case of the overloads to trabsformational intrinsics, but these are all relatively complex operations, particularly REPLACE in some of its overloads. You again have the problem of what to about illegal argument combination calls. At present the scalar call fails with a program termination if an illegal argument is used. In an elemental call this is unfriendly indeed illegal. So some sensible responce that does not cause a STOP must be implemented. > > I will set the ball rolling by saying that I can accept either way, but > would prefer to stay with our Trollhatten decision. I clearly do not agree with this view. I am strongly opposed to making the transformational intrinsic procedure overloads elemental, particularly REPEAT. I would prefer not to make the substring manipulation procedures elemental either but could be persuaded about these. > > The development body consists of me, Lawrie, Steve, Lars, someone to be > nominated by DIN. If you would like to join, please tell me. > -- Lawrie Schonfelder Director, Computing Services Dept. The University of Liverpool, UK, L69 7ZF Phone: 44(151)794 3716, Fax: 44(151)794 3759