DEC Extensions for GNU Fortran

[Paul Richard Thomas]

I agree with all the remarks from Tobias and Steve.

At least the FSF hassle will give you time to synchronize with 4.10.0!

Fine by me... and thanks, by the way!

Paul

On 29 September 2014 23:54, Steve Kargl
<sgk@troutmask.apl.washington.edu> wrote:
> On Mon, Sep 29, 2014 at 11:25:51PM +0200, Tobias Burnus wrote:
>>
>> Fritz Reese wrote:
>> > One major issue is that the DEC extensions have no real (open?)
>> > standard. There are those who believe this is a Terrible Thing and
>> > obviously new code should be written to the standard and why would you
>> > ever need these extensions. There are also those who claim there are
>> > codebases old enough to use DEC extensions and large enough that
>> > rewriting them to standard is impractical or unaffordable so why not
>> > support these extensions.
>> >
>> > The other major issue I've encountered is that Nobody has Done It.
>>
>> There is are three others:
>>
>> * At least some of them cannot be enabled by default as they will cause
>> standard conforming code to fail. The solution is to disable at least
>> some of them by default. [That matches your proposal.]
>>
>> * Adding larger new features are prone to cause regressions. [Generally
>> true.]
>>
>> * Maintenance burden: Once the feature is in, it has to be supported for
>> years, that includes fixing corner cases - even if the original author
>> is no longer available.
>>
>>
>> > I am reviving this discussion only because I have tackled one of the
>> > major issues: I have implemented and tested support for a number of
>> > DEC extensions in GNU Fortran (from the 4.8.3 release).
>>
>> Before you submit any of those patches: Those will really not fall under
>> the trivial patches, i.e. you will need a copyright agreement with the
>> Free Software Foundation. (Sending patches without copyright assignment
>> make it harder for others to implement features as they have to be then
>> different enough to not be regarded as being based on posted patches
>> with the 'wrong' copyright.)
>>
>> > All regression tests pass and I have drafted new documentation and a new testsuite.
>> > All of these extensions as I implemented them are enabled only by
>> > compile-time flags so the compiler's behavior is unchanged by default
>> > (there is the possibility to give nice errors for things that look
>> > like DEC extensions).
>>
>> Be careful with .XOR. and structure access and user-defined operators.
>> Given all the trouble that the Fortran standardization committee went by
>> introducing that pointer-returning function can be regarded as variable,
>> I think it might be difficult to get this right. Intel was also fighting
>> this (they compiler is since ifort 8 (?) 7ased on the DEC compiler). On
>> the other hand, retrofitting DEC to a compiler supporting Fortran 90+
>> might be easier than converting a Fortran 77 compiler with DEC extension
>> to F90+.
>>
>> > So I raise the question of which of the aforementioned issues is more
>> > heinous. Is the fact that Somebody has Done It sufficient to roll some
>> > of the DEC extensions into GNU Fortran as GNU extensions? Or are they
>> > so appalling as to merit no consideration even in this light?
>>
>> I think that for most users the current legacy support is sufficient and
>> the request for newer Fortran 2003/2008 features is greater than for
>> legacy. Thus, also all developers (which work on it in their spare time)
>> are concentrating on those features. Hence, I think no one really made
>> the effort to work on those systematically. Some smaller features were
>> proposed, however.
>>
>> > For the benefit of the discussion, the following are DEC extensions I
>> > have implemented, documented, and [reg]tested:
>> >
>> > ? STRUCTURE and RECORD
>> > ? UNION and MAP
>> > ? .XOR. operator
>> > ? Radix#value literal constants
>> > ? Additional OPEN specifiers (requires runtime support in libgfortran)
>> > ? B/I/J/K type prefixes to integer intrinsics
>> > ? Degree-valued trigonometric intrinsics
>> > ? AUTOMATIC and STATIC attributes for variables
>> > ? Form feed as whitespace
>>
>> Looking at requests from users, STURCTURE - and in particular UNION rank
>> quite high, especially as the latter cannot be replaced by Fortran 90's
>> TYPE.  The .XOR. can be replaced by, e.g., XOR() - hence, it wasn't a
>> much requested feature so far - similarly for the degree versions of the
>> trigometric functions. I do not recall any request for the rest (not
>> that that means much).
>>
>> > Finally, I would like to mention that my employer and I are prepared
>> > to sign copyright assignments and have no problems submitting the
>> > modifications under the GPL.
>>
>> Good.
>>
>> Tobias,
>> who is in principle fine with the changes ? but also wants to hear from
>> others.
>
> Sorry about not editing the above but I want to ensure that no
> context is lost.
>
> I agree with Tobias in that I'm in principle fine with the proposed
> changes.  There are, however, a few caveats. ;)
>
> 1. Copyright assignment.  You have indicated that you and your employer
>    are willing to assign copyright, so this isn't as problem (other
>    than usual hassle with FSF Legal paperwork).
>
> 2. Break each item in your list above into separate reviewable patches.
>    One big patch would be (1) difficult to review and (2) if a portion
>    needs to be reverted, easier to revert.
>
> 3. The patch needs to be against HEAD.  4.8.3 and head have probably
>    divergent to some degree, and new features should appear in HEAD
>    an d be merged into branches.
>
> 4. Maintenance.  I think that this is the biggest worry.  While I
>    (and most likely others) don't expect a lifetime commitment to
>    fix issues, some indication of the amount of commitment from
>    you and your employer is merited.
>
> --
> Steve



-- 
The knack of flying is learning how to throw yourself at the ground and miss.
       --Hitchhikers Guide to the Galaxy