From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,5f39173193c39af
X-Google-Attributes: gid103376,public
X-Google-Thread: 1094ba,a97c18c9ff9b447
X-Google-Attributes: gid1094ba,public
From: dewar@merv.cs.nyu.edu (Robert Dewar)
Subject: Re: Objects in Fortran 2000
Date: 1997/03/08
Message-ID: <dewar.857827520@merv>#1/1
X-Deja-AN: 223976627
References: <01bc280b$32c42d40$dac32299@default>
 <5fmemp$bgo@fg70.rz.uni-karlsruhe.de>
Organization: New York University
Newsgroups: comp.lang.fortran,comp.lang.ada
Date: 1997-03-08T00:00:00+00:00
List-Id: <comp.lang.ada>


Thomas says

<<By now, it would almost make more sense to add Fortran features
(especially HPF) to the next Ada standard than to add more
object-oriented features to Fortran.

What's missing in Ada that is present in HPF or Fortran 95?  I
can think of the following, and hope that others will extend the
list:

- FORALL (similar to a DO loop in Fortran, or a for loop in
  Ada, except that the order of execution isn't specified,
  so that automatic paralellization is very easy)

- PURE subroutines, which can't have any side effects (checkable by
  the compiler).  Ideal for sticking into FORALL statements.

- Built-in array arithmetic (quite easy to do with a library in Ada)

I don't think these concepts would 'spoil' Ada, and it does have
a cleaner overall design than Fortran.>>


Robert replies

With regard to FORALL, those with an old enough archive of CLA can find
a very extensive discussion of this point (or was it on the VR list)?
Actually I think it was on the VR list, I seriously argued for including
the forall (spelled for all, how else??) in Ada, but one of the strong
arguments against it was that a number of significant parallel Fortran people
argued against it, claiming that modern compilers can always, ir
or at least almost alway, extract this information, so it ends up being
unuuseful over-specification.

An easy way to put this in would be as a pragma applied to the loop label.
The pragma would say thto the compiler: the semantics of this loop does
not depend on the order of elaboration

Actually we could do it just by pragma placement:

    for x in ... loop
       prama Any_Order;
       ...

As to Pure, GNAT already has this feature, added in GNAT 3.09:


   A new pragma Pure_Function allows an individual function to be specified
   as Pure, see documentation in the GNAT reference manual for full details.

   That is a quote from the features file. Be sure to read the GNAT reference
   manual, there are lots of interesting pragmas and attributes. Of course if
   you use them, your code may not be portable to non-GNAT compilers, but it
   will be portable among diferent GNAT compilers.

The built-in array arithmetic is not so easy to do efficiently, but is
certainly doable. Much harder is the extensive slicing capability and
aggregate capability of Fortran-90 (f90 is a BIG language, in some
respects much larger than Ada).

In GNAT 3.10, there is a GNAT.Spitbol package that provides extensive
mimicking of SNOBOL4 capablity as implemented by Spitbol. The intention
here is to introduce a series of packages GNAT.xxx for various languages.