(j3.2006) Optional parts of programming languages
William B. Clodius
Fri Aug 24 13:28:28 EDT 2007
On Aug 23, 2007, at 10:31 AM, Aleksandar Donev wrote:
> Robert Corbett wrote:
>> Of course, the existing Fortran standard has significant optional
>> All of Chapter 14 is optional.
> Wrong! The functionality of it is optional, because it depends on
> hardware support. But the syntax (which is trivial here because it is
> just a module) must be recongnized by the compiler and processed
>> Chapter 15 should have been optional.
> Wrong again!
>> As it stands, an implementor must supply a C compiler or something
>> equivalent to a C compiler (see Section 2.5.10) to conform to the
>> Fortran standard.
> Wrong. Which part of "it may be the Fortran processor itself," is not
> In both cases the syntax is standardized and all compilers must
> recognize it, parse it, and verify it. Other than that they need not do
> anything more. BIND(C) can simply be thrown out, for example. It does
> not change the meaning of a Fortran program. It merely adds some
> conditions that the compiler should verify (i.e., is this interface
> really interoperable).
But in any important way there is no significant difference between a
feature that is optional but whose presence/absence must be documented,
and a feature whose functionality is optional beyond reporting its
presence/absence when encountering code relying on a feature. The
requirements for C compatibility are stronger than you suggest, as some
additional argument passing capability etc will have to be implemented
by the vendor. The primary difference for these two features and other
proposed optional features is that there is a strong existing demand
for the functionality, and there is a high potential cost in providing
those features for some systems, that are a minority among currently
used systems. As a result there was strong confidence that these
features would be implemented for the majority of Fortran systems,
probably all systems for which there was a demand, and as a result
optionality has a minimal impact on portability.
> It is exactly the same situation with co-arrays. Compilers must know
> syntax, parse it, verify it, and then they can simply throw away all
> square brackets and put no ops for syncs. It is as optional as a
> language feature should ever get. We are serving programmers, not
> compilers. Programmers should not have to maintain two versions of
> code just because some compiler writers or Fortran teachers do not want
> to do a little extra work.
Co-arrays are a bit harder to implement than that, but it is true that
for systems that cannot usefully parallelize the code, the impact on
implementation is minor and the other vendors which can parallelize
such code will view the additional effort of implementing the full
semantics as more than worthwhile to their customers. The cost/benefit
tradeoff is clearer than for other features proposed for the language.
The real problem with optionality is that it often has a strong
negative impact on the benefit that the language feature would
otherwise provide. If a feature is not widely portable, it will not be
widely used, and if it is not widely used it will not be widely
More information about the J3