From J.L.Schonfelder@liverpool.ac.uk Thu Mar 3 09:35:28 1994 Received: from mailhub.liverpool.ac.uk (mail.liv.ac.uk) by dkuug.dk with SMTP id AA19692 (5.65c8/IDA-1.4.4j for ); Thu, 3 Mar 1994 10:39:45 +0100 Received: from 138.253.31.200 by mailhub.liverpool.ac.uk with SMTP (PP) id <12925-0@mailhub.liverpool.ac.uk>; Thu, 3 Mar 1994 09:35:28 +0000 From: "Dr.J.L.Schonfelder" Message-Id: <9403030935.AA23201@uxb.liv.ac.uk> Subject: User Functions in Spec Expr To: SC22WG5@dkuug.dk (SC22/WG5 members) Date: Thu, 3 Mar 1994 09:35:28 +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: 3737 X-Charset: ASCII X-Char-Esc: 29 Here is a draft of a proposal on the above subject arising from discussion at X3J3 meeting 128. I would welcome comments before I put a final copy in for the meeting 129. --------------------------------------------------- To: X3J3 and WG5 (2 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). 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 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