Subject: 2 more items

From: [email-masked] (Mary E Zosel)
Date: Wed, 2 Dec 92 16:46:56 -0800

To: F90 subgroup

Two more items for us to discuss came to my attention since the first
note a while ago.  I would like to start you thinking about them.

(1) Metcalf asked if we had considered BIT_SIZE  for the subset. This
intrinsic gives back the number of bits in integers for various values
of KIND ... without KIND in the subset, I guess it would give back the
value of the default integer size.  Comments?  

(2) My records show that we voted not to have the EXTRINSIC directive
in the subset.  Is this a mistake?  We KNOW there is going to be
a need to escape HPF for system things, for messages, for ... do we
just close our eyes and let vendors do what comes in the subset - or
do we at least provide the directive that declares an external being
called is not a regular part of the HPFF data-parallel, SPMD world.
As the keeper of the subset chapter, I think we should make a
recommendation about this to the full committee. 

   -mary-

---

From: David Presberg <[email-masked]>
Date: Thu, 3 Dec 1992 19:33:33 -0500

------- Start of forwarded message -------
[Resending message that had bad addresses the first time around]

Date: Thu, 3 Dec 1992 18:23:18 -0500
From: David Presberg <[email-masked]>
Message-Id: <[email-masked]>
To: [email-masked] (Mary E Zosel)
Cc: [email-masked], [email-masked],
        [email-masked]
Subject: 2 more items

 > To: F90 subgroup

[Although I've not been at the sub-comm. mtgs, I've been following email...]

 > ...

My reading is that since BIT_SIZE takes an integer argument (no
particular reference to non-default KINDs appears in the definition of
BIT_SIZE or any of the sections related to it), it can certainly hand
back a sensible value for the default integer type.  I can certainly
see how BIT_SIZE could be very handy since we have ISHFT, etc., all of
which are defined with constraints in terms of BIT_SIZE.  Most
compilers ought to handle an invocation of BIT_SIZE as a
"compiler-generated literal", i.e., there is NO burden on
library-writers.

 > in the subset. ...

My records show the vote as:
  "To remove EXTRINSICs from the subset 11y 8n 4a" [Chuck?]  
My vague month-and-a-half recollection is that there were some final
misgivings about some more wordsmithing that might have still been
needed after the October meeting, and that there was a fairly hefty
support burden at interfaces and with libraries and/or intrinsics [sic]
that might not be absolutely required if a vendor wasn't going
to support EXTRINSICs first time out.

I guess we all expect that any vendor shipping an "extended subset"
will do the standard things in the standardly specified way.  Yeah?

 > ...  Is this a mistake? ...
 >   ...
 > recommendation about this to the full committee. ...

I think it might be better to NOT reconsider this exclusion at this
time, assuming my assumption at the end of my previous remark is
valid.

 >    -mary-

- -- Pres

p.s.  Mary, you had best bring YOUR copy of the _Fortran 90 Handbook_
next week:  I will not be able to attend the meeting.

- - -----------------------------------------------------------------
- - David L. Presberg, Parallel Systems Software Engineer, CNSF/TIG
- - 740 Engineering and Theory Center Building, Cornell University,
- - Ithaca, NY 14853-3801 607-254-8861 [email-masked]
- - Nickname: Pres
- - -----------------------------------------------------------------
------- End of forwarded message -------

---

From: Bob Knighten <[email-masked]>
Date: Thu, 3 Dec 92 17:22:24 PST

As one of those who voted against including EXTRINSICs in the subset, it was
based on the simple observation that it is not likely to be in the early
release of our HPF compiler and so including it in the subset would violate
the purpose of the subset.  

-- Bob

Robert L. Knighten	             | [email-masked]
Intel Supercomputer Systems Division | 
15201 N.W. Greenbrier Pkwy.	     | (503) 629-4315
Beaverton, Oregon  97006	     | (503) 629-9147 [FAX]