Path: utzoo!utgpu!water!watmath!clyde!att!rutgers!mailrus!uflorida!novavax!hcx1!hcx2!bill
From: bill@hcx2.SSD.HARRIS.COM
Newsgroups: comp.lang.fortran
Subject: Re: FORTRAN 8x parser/lexer .NE. compil
Message-ID: <44400026@hcx2>
Date: 22 Oct 88 21:32:00 GMT
References: <656@convex.UUCP>
Lines: 51
Nf-ID: #R:convex.UUCP:656:hcx2:44400026:000:2976
Nf-From: hcx2.SSD.HARRIS.COM!bill    Oct 22 17:32:00 1988


Kurt Hirchert (hirchert@uxe.cso.uiuc.edu) writes:
> On the other hand, I think Steve is right on track with his concerns
> about the cost of optimizing/vectorizing the array language.  If most of
> the opponents of the Fortran 8x draft were expressing concerns about the
> amount of effort to generate efficient code for the array language, I
> could take their concerns about complexity more seriously.  Instead, I
> see most of those opponents supporting the array language and a number of
> vendors already implementing it.

Well I, for one, have been expressing concerns about the array language.
I think it will cause scalar machines particularly to run like molasses
in Alaska.  So why, you ask, am I supporting the array language?  I am
supporting the CONCEPT of the array language, but I have real problems
with some of the details.  I think there are so many users who are
running, or would like to run, the same code on both supercomputers
and scalar machines (even PCs!), that some kind of array language is
a must for portability.  I would like, however, to see it scaled
back somewhat from the 8x draft.

The reason that I, and I suspect others, have not harped on the array
language is because we recognize its importance.  The fact, though,
that the array language adds significant complexity makes us all the
more reluctant to accept much else.  Its like a young couple buying
their first house: they recognize they _need_ a house, but it doesn't
have to have gold-plated fixtures.  We simply can't afford the effort
required for the 8x array language AND all the other stuff too.

Dependent compilation has gotten a lot of attention here, so I'll
put in my two-cents worth.  The fact is, the 8x draft doesn't nail
down nearly enough of the requirements of MODULE/USE to know how
to implement it.  For instance, the standard does not say what the
behavior should be if a program USEs a MODULE, then the MODULE
is modified and recompiled.  The obvious response is, it should
be an error to do this.  But you can't give an error if MODULE/USE
is implemented as a fancy INCLUDE.

Exactly, you say!  So how come INCLUDE is better, you shout?  The
difference is that the user _knows_ that INCLUDE is just that, an included
file, but MODULEs get compiled!  INCLUDE files never get compiled, so there
is no expectation from the user that such recompilation will fix all the
references, or at least tell him he screwed up.  The opposite is true for
MODULEs; the user expects that the compiler will remember that the MODULE
was recompiled, and tell him if something else needs to be recompiled.
Also, remember that by the time 8x is out, lots of people will have had
experience with Ada, and that will color their expectations.

But it's worse yet: MODULEs can contain procedures!  So a USE of the MODULE
can't be implemented as a simple INCLUDE: the compiler needs to selectively
include information from the MODULE.  This is certainly more complex than
just INCLUDE.