X3J3/96-155

Date:       October 3, 1996
To:         X3J3/WG5
From:       Keith Bierman
Subject:    Strategic Direction of the Language


One of the less than completely settled matters coming out of Dresden
is the question of strategic direction of the language. While little
(if any) of what follows is new, I don't recall seeing it in a
paper. So, for the record.

During my tenure at Sun, I've spent a lot of time over the last 8
years meeting with a wide variety of customers regarding their Fortran
needs, motivation for coding in Fortran.

While there is no single ranking among the top three issues, there are
precisely three issues which are orders of magnitude more important to
the vast majority of Sun users that I have consulted with. They are:

    *) legacy code : If it ran yesterday (or last decade) they want it
		     to run tomorrow (and next decade) unchanged.

    *) performance : They want their Fortran applications to run at
		     close to advertised peak speeds, or at least
		     faster than anything short of assembly language.

    *) portability : They want to be able to move their code from
		     processor to processor without changes to the
		     code, to the build environment, or need to
		     explain away differences in answers.

My own experience on the consumer side confirms this, for what an
individual (albeit at a wide variety of sites) observation is worth.

Now this isn't to say that all customers place the same values on
these three; nor even that the same customer can't be induced to trade
one off against another.

    Sometimes, some customers are prepared to make major changes to
    get major (2x-100x) speedup.

    Sometimes, fewer customers are prepared to make major changes to
    get minor (10%-30%) speedup.

etc.

It might be worth doing a straw vote on the first half of this paper
to record the committee's sentiments in this area.


As a result of this trinity of user requirements, I am most in favor
(and think the committee(s) should be too) extending Fortran in ways
that directly address these three issues, and should avoid extensions
that put some or all of these at risk.

Protection of legacy code starts with our ceasing to work towards
removing bits of the language. While it might make our language "more
elegant" or "more modern" or easier to write the Standard, it makes it
vastly less marketable.

For performance we should consider continued HPF or leveraging the
experience with compiler directives into augmenting the language
syntax to allow programmers to assert things about their program that
can be useful to the optimizer. We should also refrain from adding
language features which are known or even strongly suspected of
adversely impacting performance (unless and until Fortran
processor implementations of such ideas exist and provide the proof
that performance need not be sacrificed for the feature).

For portability we should analyze some of the reasons why people feel
a need for conditional compilation and solve the problem. We should
start "binding to POSIX" to nail down the OS features used to
implement Fortran. We should consider cannonizing compiler flags, and
features of the environment so that build scripts/makefiles can be
made portable. And, of course, we should pursue interval arithmetic,
so that numeric results can be automatically compared for consistency
across platforms. We should avoid putting in new features which
decrease portability (such as the new kinds available to system_clock;
if processor A supports default kind and "kind=8, but processor B only
supports default kind, it is easy to see how a code written on A will
fail to compile on processor B; before the programmer would have
written a call and it would have worked anywhere. If we had introduced
an inquiry function, it would be possible to write a portable program
again. However, if every feature of the language needs an inquiry
function, programming will be excessively hard. Clearly, we need to
solve a basic problem (and I don't have an answer).

It's fine for us to be "above" defining the details of how, say,
modules work ... but it makes it insanely difficult for users to port
code, etc.

These mundane issues impact more users more directly, than making the
language arbitrarily extensible, OOF (or otherwise), etc.