From J.L.Schonfelder@liverpool.ac.uk Tue Mar 15 10:28:27 1994 Received: from mailhub.liverpool.ac.uk (mail.liv.ac.uk) by dkuug.dk with SMTP id AA27195 (5.65c8/IDA-1.4.4j for ); Tue, 15 Mar 1994 11:28:28 +0100 Received: from liverpool.ac.uk by mailhub.liverpool.ac.uk with SMTP (PP) id <03311-0@mailhub.liverpool.ac.uk>; Tue, 15 Mar 1994 10:28:29 +0000 From: "Dr.J.L.Schonfelder" Message-Id: <9403151028.AA26775@uxh.liv.ac.uk> Subject: functions in specification expressions To: SC22WG5@dkuug.dk (SC22/WG5 members) Date: Tue, 15 Mar 1994 10:28:27 +0000 (GMT) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 4696 X-Charset: ASCII X-Char-Esc: 29 Here is a draft paper on this subject. I would welcome comments and am prepared to modify the proposal in light of any such. However as I will be at a meeting all next week it is quite likely that unless the comments are prompt I will not have time to do anything much before the x3j3 meeting 129 distribution deadline. (David, please put this tentatively in the distribution. I will try to get any necessary update to you before the cutoff and will put paper {postscript} version with fonts etc in the post) ------------------------------------------------------------------ To: X3J3 and WG5 (14 March 1994) From: Lawrie Schonfelder User Functions in Specification Expressions 1 Introduction This paper is in response to votes taken on the above topic at meeting 128 of X3J3. This meeting favoured allowing user defined PURE functions accessed from a module to be used in specification expressions. Although it is believed that there are as yet unsolved problems with allowing user functions in general in specification expressions, there are no significant problems with this restricted class of functions. 2 Technical Description The restrictions that are to apply to functions that will be permitted to appear in specification expressions are:  the functions must be declared with the PURE prefix,  the functions must be directly accessed by use association or they must be accessed by host association from a host that gained access via use association.  the arguments of such functions when used in a specification expression must be restricted expressions,  the functions must not appear in any context which requires a constant specification expression, e.g. any specification not in a subprogram or an interface body, in a common or equivalence specification, or a component specification, and,  any object whose specification depends on such a function is an automatic object and hence cannot be saved or initialised. 3 Suggested Edits The following are suggested edits to implement this change. They are written against the current standard. However, this area of the text is very complex and subject to major redrafting. These edits therefore may well need to be fairly comprehensively recast. 3.1 Rationale A significant number of useful applications will be facilitated by the ability to perform more complicated calculations when specifying data objects than are permitted with Fortran 90. This will be very substantially achieved by allowing a restricted class of non-intrinsic functions in specification expressions. 3.2 5.1 [40/41] Before "If" add the sentence A specification expression is considered to be non-constant if it involves a reference to a specification function (7.1.6.2). { I think this edit is sufficient to make any object declared with a specification involving such a function an automatic object. } 3.3 7.1.6.2 [78/37+] Add paragraph A function is a specification function if it is a function defined with the PURE prefix, is accessible via use association or via host association from a host that accessed it via use association { This definition allows external procedures that are defined entirely independently and accessed via an interface block declaration in a module. This is slightly wider than was discussed at meeting 128 but I can see no additional problem caused by this and no reason for adopting the more restricted definition which confines the specification functions to be module procedures. } 3.4 7.1.6.2 [79/16+] Add item (11) A reference to a specification function where each argument is a restricted expression. { I believe these edits to be sufficient, in spite of how few they seem. Most of the essential semantics are already covered in the text on pages 78-79. However, it should be noted that as currently defined specification expressions are excessively constrained. The really important restriction is that which distinguishes between what can appear in a constant compile-time specification and those that can occur in a specification that must be evaluated at run-time. It might be desirable to work through this whole area of expression classification making the essential restrictions clearer and relaxing the inessential. } -- 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