Re: Objects in Fortran 2000

Re: Objects in Fortran 2000

[Thomas Koenig]

In comp.lang.fortran, "Loren P. Meissner" <LPMeissner@msn.com> wrote:

>It was agreed  by WG5 in Februray 1977 that Fortran 2000 will contain
>minimal object-oriented facilities; namely:

[...]

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.
-- 
74 a3 53 cc 0b 19

Re: Objects in Fortran 2000

[Robert A Duff]

In article <5fmemp$bgo@fg70.rz.uni-karlsruhe.de>,
Thomas Koenig <Thomas.Koenig@ciw.uni-karlsruhe.de> wrote:
>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:

Well, if you add all the missing features, that won't make everybody
rewrite all their Fortran code in Ada.  It might win over some new
projects, I suppose.

>- 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)

Such a feature was considered during the Ada 9X project.  It was
rejected due to the general feeling that Ada 9X was too much.  Not due
to dislike for the feature itself.  (I don't remember the details of the
feature -- if anybody is interested, there must be old versions of those
documents around somewhere.)

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

Ada 95 has this, although it is not as fine-grained as one might like
(pragma Pure applies to a whole library-unit).

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

Yup.

- Bob

Re: Objects in Fortran 2000

[Larry Kilgallen]

In article <5fmemp$bgo@fg70.rz.uni-karlsruhe.de>, ig25@fg70.rz.uni-karlsruhe.de (Thomas Koenig) writes:
> In comp.lang.fortran, "Loren P. Meissner" <LPMeissner@msn.com> wrote:
> 
>>It was agreed  by WG5 in Februray 1977 that Fortran 2000 will contain
>>minimal object-oriented facilities; namely:
> 
> [...]
> 
> 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.

Don't mess with people's religion.

Larry Kilgallen
posting from comp.lang.ada

Re: Objects in Fortran 2000

[Robert Dewar]

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.
\x1a

Re: Objects in Fortran 2000

[Van Snyder]

In article <dewar.857827520@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) writes:
|> 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.>>

I agree that Ada's type system is more systematic that Fortran's (which is
mostly absent).

But here is something else I found attractive about Fortran 90, as compared
to Ada:  In Fortran, one can add the POINTER or ALLOCATABLE attribute to a
declaration, add an ALLOCATE and DEALLOCATE statement, and _not_touch_ the
usages.  In Ada, one needs to track down all the usages and add ".all" onto
them.  This derives from Fortran doing automatic dereferencing, and having
a separate => operator for pointer assignment.  Ada chose to use the ordinary
assignment operator for pointer assignment, and to interpret "p := q;" as
pointer assignment, and do something different to mean "dereference p and q
and copy the values."

|> Robert replies
....
|> 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.

This is exactly the point to having things like PURE as part of the language,
not as optional pragmas.

|> 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).

This is on my list, too, and Robert said it well.  I'd say Fortran is bigger
in some _areas_ than Ada, but overall, Ada is significantly bigger.

BTW, Robert, the Fortran proposal for exception/handler blocks, similar to
the way Ada does it, foundered on the semantics of the combination of
exceptions and parallelism.  Has the Ada community some insight/advice to
offer concerning the semantics of exception blocks in the presence of
parallelism?

-- 
What fraction of Americans believe   |  Van Snyder
Wrestling is real and NASA is fake?  |  vsnyder@math.jpl.nasa.gov

Re: Objects in Fortran 2000

[Robert A Duff]

In article <5gs6ub$kb3@netline-fddi.jpl.nasa.gov>,
Van Snyder <vsnyder@gyre.jpl.nasa.gov> wrote:
>BTW, Robert, the Fortran proposal for exception/handler blocks, similar to
>the way Ada does it, foundered on the semantics of the combination of
>exceptions and parallelism.  Has the Ada community some insight/advice to
>offer concerning the semantics of exception blocks in the presence of
>parallelism?

Could you be more specific?  I don't know Fortran 90.  Are you talking
about parallel "for all" sorts of loops?  Anyway, if you have multiple
parallel threads of control raising exceptions, you can wait until they
are all synchronized in some way, and then raise a single exception --
for example, the way Ada deals with exceptions during task activation by
raising Program_Error.  (For normal exceptions raised by tasks, not
during activation, Ada says the exception is ignored.  I think that's a
bad thing.)  In Ada, if an exception is raised during a rendezvous, both
tasks get the exception.

- Bob

Re: Objects in Fortran 2000

[Robert Dewar]

Bob Duff said

<<Could you be more specific?  I don't know Fortran 90.  Are you talking
about parallel "for all" sorts of loops?  Anyway, if you have multiple
parallel threads of control raising exceptions, you can wait until they
are all synchronized in some way, and then raise a single exception --
for example, the way Ada deals with exceptions during task activation by
raising Program_Error.  (For normal exceptions raised by tasks, not
during activation, Ada says the exception is ignored.  I think that's a
bad thing.)  In Ada, if an exception is raised during a rendezvous, both
tasks get the exception.>.

Fortran 90 has a SIMD model for fine grained parallelism, so the idea
of waiting or multiple threads is off base. Really the problem is mor
related to the issue of exceptions and optimization in Ada (so 11.6
is the place to look for ideas).

Re: Objects in Fortran 2000

[William Clodius]

Robert Dewar wrote:
> 
> Bob Duff said

> <<Could you be more specific?  I don't know Fortran 90.  Are you talking
> about parallel "for all" sorts of loops?  Anyway, if you have multiple
> parallel threads of control raising exceptions, you can wait until they
> are all synchronized in some way, and then raise a single exception --
> for example, the way Ada deals with exceptions during task activation by
> raising Program_Error.  (For normal exceptions raised by tasks, not
> during activation, Ada says the exception is ignored.  I think that's a
> bad thing.)  In Ada, if an exception is raised during a rendezvous, both
> tasks get the exception.>.
>
> Fortran 90 has a SIMD model for fine grained parallelism, so the idea
> of waiting or multiple threads is off base. Really the problem is mor
> related to the issue of exceptions and optimization in Ada (so 11.6
> is the place to look for ideas).

Fortran 95's Forall and Where constructs allow a MIMD model for fine
grained parallelism that provides for little if any direct communication
or cooperation between procedures executing in parallel. The closest
approximation to thread synchronization would be the end of Forall and
Where constructs. Fortran 95 also does not explicitly have a tasking
model or any of means of directly indicating that a procedure will be
executed in parallel, although the PURE and ELEMENTAL procedure
attributes are suggestive that they might be used in parallel. As a
result the proposed exception handling model did not make any useful
distinctions as to whether exceptions could be raised during parallel
vs. non-parallel execution. 

For an understanding of Fortran 200X's planned floating point exception
handling capability, I suggest an examination of SC22WG5's report N1274
available at

ftp://ftp.ncsa.uiuc.edu/sc22wg5/ftp.nag.co.uk/LATEST-DOCS/

For an understanding of the best effort at a more general exception
handling proposal for Fortran I suggest an examination of SC22WG5's
report N1257 available at the same location.

-- 

William B. Clodius		Phone: (505)-665-9370
Los Alamos Nat. Lab., NIS-2     FAX: (505)-667-3815
PO Box 1663, MS-C323    	Group office: (505)-667-5776
Los Alamos, NM 87545            Email: wclodius@lanl.gov