From helbig@man.ac.uk Sun Aug 23 19:31:19 1998 Received: from ratatosk.DK.net (root@ratatosk.DK.net [193.88.44.22]) by dkuug.dk (8.6.12/8.6.12) with ESMTP id TAA00317 for ; Sun, 23 Aug 1998 19:31:17 +0200 Received: from multivac (multivac.jb.man.ac.uk [130.88.24.128]) by ratatosk.DK.net (8.8.8/8.8.8) with SMTP id RAA24898 for ; Sun, 23 Aug 1998 17:05:56 +0200 (MET DST) Date: Sun, 23 Aug 1998 16:06:35 GMT Message-Id: <98082316063525@man.ac.uk> From: helbig@man.ac.uk (Phillip Helbig) To: SC22WG5@dkuug.dk Subject: Re: (SC22WG5.1534) String standard, module and F95 X-VMS-To: SC22WG5@DKUUG.DK X-VMS-Cc: HELBIG From: SMTP%"j.l.schonfelder@liverpool.ac.uk" 23-AUG-1998 16:02:49.90 To: Malcolm Cohen CC: SC22WG5@dkuug.dk Subj: (SC22WG5.1534) String standard, module and F95 On Wed, 12 Aug 1998 10:15:47 +0000 (BST) Malcolm Cohen wrote: > Lawrie complains about the restriction, for ELEMENTAL procedures, that dummy > arguments cannot appear in specification expressions (other than in certain > very limited contexts) - in particular, they cannot be used to dimension > automatic arrays. > > I agree with Lawrie that this restriction is > (a) unnecessary > (b) not useful > (c) irritating > > I don't agree that it is "entirely unfathomable" though - the reasons for > doing this were made clear, even if one disagrees with them. The only reason that was advanced in the standard was that it aided certain optimisations. This is hardly sufficient reason even if I am prepared to withdraw the "entirely". I question the validity of the statement. As Malcolm points out below I can write a version of the split routing that depends of an allocatable array instead of an automatic length character working variable. This significanly changes the code and adds a number of allocates and deallocates that were not there before (some were probably there under the covers in this case since I used the assignment overload in the character form). I have not run any tests to see whether the new version is faster than the old but it was slower to write! In general if you need to produce routines with this sort of dynamic working variable dependency that are also required to be elemental (which I believe is widespread need for anyone building data-abstractions) you will need to employ allocatable arrays rather than automatic ones. I may be naive but I have always thought automatic objects built on the stack were more efficient that allocatable ones built on the heap. They are certainly much simpler for the programmer to use. I can only say it is perversely unfortunate for yet another situation to have been allowed to be created which forces allocatables to be used where automatic would be the obvious choice. > > In any case it does not prevent the SPLIT subroutine being made elemental, > since ALLOCATABLE arrays are allowed in ELEMENTAL procedures. > > Using an ALLOCATABLE array instead of an automatic array should not cause any > loss of machine efficiency, and only a slight loss of programmer efficiency > other than the irritation caused by getting an error message for the original > attempt using an automatic array - of course this latter part could be > substantial! > > Anway, since the conversion is so straightforward, it rather begs the question > of why not let the compiler effectively do the conversion (when needed) instead > of requiring it of the user. Why not let the compiler detect situations where automatics are not used and do whatever optimisations were contemplated and not do them if automatics are required but allow the user to use them when they are appropriate. I will lay odds that the optimisations will not and cannot be done if allocatables are employed! An increasingly disallusioned ex-standard developer and user. Regards -- Lawrie Schonfelder Director, Computing Services Dept. The University of Liverpool, UK, L69 7ZF Phone: 44(151)794 3716, Fax: 44(151)794 3759 ================== RFC 822 Headers ================== Return-Path: owner-ukfortran@lists.ed.ac.uk Received: by multivac.jb.man.ac.uk (UCX V4.1-12, OpenVMS V7.1 Alpha); Sun, 23 Aug 1998 16:02:31 GMT Received: from [129.215.128.53] (helo=haymarket.ed.ac.uk) by curlew.cs.man.ac.uk with esmtp (Exim 1.92 #2) for helbig@man.ac.uk id 0zAbe0-0000P8-00; Sun, 23 Aug 1998 16:01:24 +0100 Received: (from majordom@localhost) by haymarket.ed.ac.uk (8.8.7/8.8.7) id QAA07347; Sun, 23 Aug 1998 16:00:42 +0100 (BST) Received: from ptah.dkuug.dk (ptah.dkuug.dk [195.215.30.66]) by haymarket.ed.ac.uk (8.8.7/8.8.7) with ESMTP id QAA07337 for ; Sun, 23 Aug 1998 16:00:40 +0100 (BST) Received: (from daemon@localhost) by dkuug.dk (8.6.12/8.6.12) id QAA25790 for SC22WG5-list; Fri, 21 Aug 1998 16:30:11 +0200 Message-Id: <199808211430.QAA25790@dkuug.dk> From: Lawrie Schonfelder X-Sequence: SC22WG5@dkuug.dk 1534 Reply-To: j.l.schonfelder@liverpool.ac.uk To: Malcolm Cohen Cc: SC22WG5@dkuug.dk Subject: (SC22WG5.1534) String standard, module and F95 In-Reply-To: <199808120918.LAA00718@dkuug.dk> Date: Fri, 21 Aug 1998 15:29:34 +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 Sender: owner-ukfortran@lists.ed.ac.uk Precedence: bulk