(j3.2006) Optional parts of programming languages

[William B. Clodius]

On Aug 23, 2007, at 10:31 AM, Aleksandar Donev wrote:

> Robert Corbett wrote:
>
>> Of course, the existing Fortran standard has significant optional 
>> parts.
>> 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
> accordingly.
>
>>  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 
> clear?
>
> 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 
> the
> 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 
> their
> 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 
portable.


-- 
William Clodius