From zongaro@VNET.IBM.COM  Thu Jan  2 18:52:56 1997
Received: from VNET.IBM.COM (vnet.ibm.com [199.171.26.4]) by dkuug.dk (8.6.12/8.6.12) with SMTP id SAA10284 for <sc22wg5@dkuug.dk>; Thu, 2 Jan 1997 18:52:50 +0100
Received: from TOROLAB by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 9585;
   Thu, 02 Jan 97 11:51:05 EST
Received: by TOROLAB (XAGENTA 4.0) id 1315; Thu, 2 Jan 1997 11:50:11 -0500 
Received: by twinpeaks.torolab.ibm.com (AIX 4.1/UCB 5.64/4.03)
          id AA03900; Thu, 2 Jan 1997 11:51:07 -0500
From: <zongaro@VNET.IBM.COM> (Henry Zongaro)
Message-Id: <9701021651.AA03900@twinpeaks.torolab.ibm.com>
Subject: Re: PURE/ELEMENTAL for C procedures?
To: hennecke@rz.uni-karlsruhe.de
Date: Thu, 2 Jan 1997 11:51:05 -0500 (EST)
Cc: sc22wg5-interop@ncsa.uiuc.edu, sc22wg5@dkuug.dk
In-Reply-To: <199612211852.MAA09886@newton.ncsa.uiuc.edu> from "Michael Hennecke" at Dec 21, 96 07:52:06 pm
X-Mailer: ELM [version 2.4 PL24alpha3]
Content-Type: text
Content-Length: 2159

Hi Michael,

> F95 restricts PURE and ELEMENTAL to subprograms, and places a number of
> restrictions on the (Fortran) definition of such subprograms (e.g. no
> print-stmt or other external I/O shall appear). This allows compile-time
> checking of some of the factors that may prevent the PUREness of such
> subprograms.
>
> As it stands, a procedure defined by means of C which has an explicit
> interface (with the BIND(C) prefix) is not allowed to have the PURE or
> ELEMENTAL attribute, because it is not a subprogram. It is also not
> possible to ``hide'' this procedure defined by means of C in a PURE
> (Fortran) wrapper subprogram because all references to procedures within
> such a PURE subprogram must also be pure.
>
>   QUESTION:
>   Should this restriction be relaxed, simply believing the programmer who
>   specifies PURE in an explicit interface for a procedure even if this case
>   compile-time checks are, in general, impossible?
>
> Needless to say that writing down the words to say that the results are
> undefined if the procedure actually is not PURE will be a difficult task...

     I personally wouldn't have a problem with permitting pure and elemental
for procedures written in C.  One possible concern with elemental, however,
lies in the implementation strategy that an implementor might take.

     The more obvious implementation strategy for elemental procedures would be
for a processor to generate loops around the reference to the elemental
procedure, one loop for each dimension of the result; the elemental procedure
would be called once for each element.  Another possibility would be for the
implementation to pass in descriptors or dope vectors for any arguments, and
the processor would generate code *inside of the elemental procedure* to decode
the dope information, and evaluate each element of the result without the
overhead of a procedure call for every element.

     The second implementation strategy wouldn't work with procedures compiled
in other languages.  Now, I don't know whether any implementors have chosen or
will choose to implement elemental procedures the second way.

Thanks,

Henry