DEC Extensions for GNU Fortran

[FX]

I agree strongly. Let's not invent our own new standard, and let extensions interact as little as possible with newer standard features. Unless there is proof of significant use of such mixtures in real life code.

FX



Le 16 oct. 2014 à 17:00, Fritz Reese <fritzoreese@gmail.com> a écrit :

> Thought I'd provide an update on my status - I'm still working on
> legal stuff. Progress is slow but sure. I wanted to get an opinion
> from the crowd while I clean up my patches and rebase from trunk:
> 
> Do you think the addition of UNION/MAP should be a self-contained
> patch where UNIONs are usable within derived types, or should they be
> tied to STRUCTURE/RECORDs? Right now I do not allow UNION/MAP inside
> F90 derived TYPEs, only in DEC STRUCTUREs (enabled with
> -fdec-structure). Because of my implementation it would not be
> difficult to allow this, but I didn't think it made sense since TYPE
> actually has a standard and STRUCTURE doesn't anyway. Thoughts?
> 
> On 29 September 2014 23:54, Steve Kargl
> <sgk@troutmask.apl.washington.edu> wrote:
>> [..........]
>> 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.
> 
> I am happy to help maintain my extensions if [when? :-)] they break anything.
> 
> ---
> Fritz Reese
> 
> On Tue, Sep 30, 2014 at 4:13 AM, Paul Richard Thomas
> <paul.richard.thomas@gmail.com> wrote:
>> 
>> Dear Andrew,
>> 
>> I am working 100% on fortran-dev, which still thinks that it is
>> 4.10.0.  Apologies! 5.0 it is :-)
>> 
>> Cheers
>> 
>> Paul
>> 
>> On 30 September 2014 09:45,  <pinskia@gmail.com> wrote:
>>> 
>>> 
>>> 
>>> 
>>>> On Sep 29, 2014, at 9:12 PM, Paul Richard Thomas <paul.richard.thomas@gmail.com> wrote:
>>>> 
>>>> 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!
>>> 
>>> I think you mean 5.0 :).
>>> 
>>> Thanks,
>>> Andrew
>>> 
>>>> 
>>>> 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
>> 
>> 
>> 
>> --
>> The knack of flying is learning how to throw yourself at the ground and miss.
>>       --Hitchhikers Guide to the Galaxy