Design PRIVATE procedures in ABSTRACT

[Blane_J_]

Hi, I'd like to ask anyone for ideas of designing ABSTRACT derived-type. Generally, ABSTRACT type is a model for the descendant derived-types. Procedures designed in it ought to be public if it is deferred because a private one can not be referenced or overridden out of the module itself. But how can I design the ABSTRACT derived-type if I want each and every one of the descendants to have a same functional PRIVATE procedure to do something(eg. to do some specific generic work) ? Am I have to manually define them in each descendant or can I put a model in the ABSTRACT and implement it in the descendant ? Thanks for any reply.

[Blane_J_]

Here I put an example to illustrate the situation:

module test1
    implicit none
    
    private
    public :: tp1

    type, abstract :: tp1
    contains
        private
        generic, public         :: operator(+) => add
        procedure(op), deferred :: add
    end type tp1
    
    abstract interface
        function op(a, b)
            import :: tp1
            class(tp1), allocatable :: op
            class(tp1), intent(in)  :: a
            class(tp1), intent(in)  :: b
        end function op
    end interface

end module test1
    
module test2
    use test1, only: tp1
    implicit none

    type, extends(tp1) :: tp2
        private
        integer :: value
    contains
        private
        procedure, public :: add => add_tp2
    end type tp2

    contains
    
    function add_tp2(a, b)
        class(tp1), allocatable :: add_tp2
        class(tp2), intent(in)  :: a
        class(tp1), intent(in)  :: b
        ! DO SOME ADDITION.
    end function add_tp2

end module test2

In the example, the descendant derived-type tp2 is a non-abstract type and inherits a deferred binding, so the procedure add must be overridden. But the procedures are defined private in tp1, that is to say it can not be overridden outside of module test1, so defination of tp2 above is invalid. What should I do ?

[FortranFan]

Blane J. wrote:

.. In the example, the descendant derived-type tp2 is a non-abstract type and inherits a deferred binding, so the procedure add must be overridden. But the procedures are defined private in tp1, that is to say it can not be overridden outside of module test1, so defination of tp2 above is invalid. What should I do ?

"What should I do ?" - well, you know the answer to your own question:  you can either make your deferred procedure public or make the extended type part of the same module as the abstract parent type.  These are the only two straight-forward options available per the current Fortran standard.  

[Blane_J_]

FortranFan wrote:

Quote:

"What should I do ?" - well, you know the answer to your own question:  you can either make your deferred procedure public or make the extended type part of the same module as the abstract parent type.  These are the only two straight-forward options available per the current Fortran standard.  

Thanks, FortranFan.

For the first answer, if the deferred procedure add is made PUBLIC, then it can be referenced as   % add()   syntax which violate my origin that only operator(+) should be the reference interface.

For the second answer, if there are many more descendants ( assume a hundred ) of the abstract type, wouldn't it be so large for the module test1 ?

[FortranFan]

Blane J. wrote:

.. For the first answer, if the deferred procedure add is made PUBLIC, then it can be referenced as   % add()   syntax which violate my origin that only operator(+) should be the reference interface.

For the second answer, if there are many more descendants ( assume a hundred ) of the abstract type, wouldn't it be so large for the module test1 ?

Note you're constrained by the Fortran standard. 

(Edit 1/7/2018)

[Blane_J_]

FortranFan wrote:

work with what you got or leave it altogether.

Oooooops, If so, that would really be a pity to the few of us.

[Steve_Lionel]

Please note that FortranFan's opinions of the "mindset" of the Fortran standards committee are his own, and don't necessarily reflect the opinions of committee members. In the nine years I've been on the committee, I have never heard such positions voiced by any member.

[Blane_J_]

Thanks Steve, and I hope the standards in the future release can support more on OOP programming.

[Steve_Lionel]

There's still time to offer your suggestions for the next standard. https://wg5-fortran.org

[Blane_J_]

Steve Lionel (Ret.) wrote:

There's still time to offer your suggestions for the next standard. https://wg5-fortran.org

Oh, yes, I then submitted a survey on the page you suggest. Thank you again, Steve.

[FortranFan]

Steve Lionel (Ret.) wrote:

Please note that FortranFan's opinions of the "mindset" of the Fortran standards committee are his own, and don't necessarily reflect the opinions of committee members. In the nine years I've been on the committee, I have never heard such positions voiced by any member.

(Edit 1/7/2018)

The underlying issue, a gap in the language that prevents Fortran coders to author a key aspect involving OO design where a procedure binding needs to be overridden but not invoked directly, has existed since the Fortran 2003 revision published back in 2004.  And the standards committee should have been acutely aware of this problem at least since the F08/0052 interp which was over 6 years ago.  What's most bothersome to me is those who working on Fortran 2003, if they had looked around just a bit, would have noticed the top languages back then included Java, C++, and Microsoft .NET languages (e.g.,C#), all of whom provided masterly OO support along with access modifiers to their 'class' facilities that went beyond 'private' and 'public' and that the computer science concepts around accessibility, particularly for inheritance, were well-established in OO parlance.  That is, the problem OP has noticed in this thread could have been avoided in the Fortran standard in the first place.  But there were 2 subsequent opportunities to address the gap: Fortran 2008 and 2018, and both got missed too.  The omission in Fortran 2008 is especially disconcerting because an effective solution to this issue may have been with the MODULE feature which did get revised considerably with SUBMODULEs and it could have been a two-for-one in terms of language improvement.

Anyways this very issue has been brought up on this forum and elsewhere, more than several times that I know of.  

[Blane_J_]

FortranFan wrote:

Quote:

But as someone mentioned on another forum, Fortranners can likely expect compiler support for that revision in year 202X+7.

As I submitted the survey mentioned above, I noticed the situation that my opinion may be accepted or not and there must be years to wait. In the mean time, possilble work around may be created if FORTRAN is still the language I have to use. BTW indeed, time between standard and supported compiler release is really exhausted.

[Steve_Lionel]

I expect that the time lag will be less for future revisions. Fortran 2008 was immense and complex. Fortran 2018 is less so, and Fortran 202x is intended to be a smaller-still increment yet still deliver useful features. Not every requested item will make it, of course.

[Blane_J_]

Steve Lionel (Ret.) wrote:

I expect that the time lag will be less for future revisions. 

Same as I do.

[FortranFan]

Steve Lionel (Ret.) wrote:

.. Fortran 2008 was immense and complex. ..

(Edit 1/7/2018)

WG5 consistently viewed Fortran 2008 as a minor update.

[Steve_Lionel]

What really did in F2008 implementation was coarrays - for vendors other than Cray, which had had a coarray implementation for a decade, there was a lot of new ground to be broken. I came in at the very end of F2008 standardization so I'm not really aware of what was going on, but F2008 on top of F2003 (even bigger) and developer resources were strained.

I'm not too hopeful on unsigned integers. It was proposed for F2008 and eventually rejected. But I can see other nice things coming. I don't agree that Fortran has a large feature deficit, and more so I think that's an inappropriate comparison. If every language was the same we'd need only one. Each language has some things where it is strong and some where it is weak. What is important is not diluting the strengths just to play copycat.

[FortranFan]

Steve Lionel (Ret.) wrote:

What really did in F2008 implementation was coarrays -..

.. I don't agree that Fortran has a large feature deficit, and more so I think that's an inappropriate comparison. If every language was the same we'd need only one. Each language has some things where it is strong and some where it is weak. What is important is not diluting the strengths just to play copycat.

By mid-2005 compiler teams would have known coarrays were definitively going to be part of the next Fortran standard revision and that it was going to be based on published work since 1998.  And one would think it was the knowledge of such work and the understanding of WG5 members themselves of the relative simplicity of factoring in the coarray design into the Fortran language framework that made them view Fortran 2008 was a minor update.  The standard revision was published almost five years later in 2010.  Implementations had a decent amount of lead time to incorporate coarrays and all the other Fortran 2008 features even on top of Fortran 2003 which itself was over 7 years in the making since Fortran 95.  It's not complexity of the features or the lack of time that is making implementations view almost each Fortran standard revision as "immense and complex" but it's something else entirely which I think is attitudinal - considerable lack of conviction and understanding of the value of the new features, inertia, resistance to change, insufficient allocation of resources, etc., pretty much the whole gamut that will be the very opposite of "7 Habits of Highly Effective Compiler Implementations of IEC ISO standard based languages".  Fortranners suffer as a result.

Re: the comment "If every language was the same we'd need only one. .. What is important is not diluting the strengths just to play copycat.", again it needs to made clear: Fortranners are already being highly discerning and understanding of Fortran's strengths and all-around limitations to seek those features and facilities that have been proven and time-tested in terms of coding and code efficiency with development time also being important perhaps more so given how compute platforms are evolving, refining code designs that can reduce bug density, improving coding security and safety, enhancing collaboration, furthering code capabilities that can tackle bigger and more complex problems say multiphysics architectures, all toward "scientific and technical" applications which WG5 says Fortran is suited for.

This thread which brings up the gap in Fortran in terms of having only two accessibility modes - private/public - of fields and methods in a given scope is but one illustration of a feature deficit relative to information hiding and OO based design.

And my point about the feature deficits in Fortran was about such modern programming needs: more and more new codes involving big teams in the broader scientific and technical domains are moving away from Fortran as a result, even if there are some counter examples.  Fortran standards committee and implementations need to do more and faster.

[Steve_Lionel]

FortranFan, your history is somewhat revisionist. By no means was it certain that coarrays were going to be part of the language - it wasn't until the August 2008 WG5 meeting (that I was at) where the matter was settled. There were strong divisions among members on this topic and it came to a close country vote.

Most vendors were also still struggling with F2003, which had broad effects on all parts of the compilers. I'll remind you that Intel had the second implementation of coarrays, after Cray (which had had them for a decade, based on an earlier academic paper and taking advantage of their unique system topology.) There is not yet another complete coarray implementation, though gfortran is getting there.

I have invited you before to join the committee and to put in the effort to design and integrate features you say programmers want. It's easy to throw stones from outside. You could even attend a couple of meetings as an observer. (More than that would require you to join as a member, per INCITS rules.) I do agree that the long gap between standard revisions is harmful, which is why I, as the new WG5 convenor, set a goal for a new revision within five years.

[FortranFan]

Steve Lionel (Ret.) wrote:

FortranFan, your history is somewhat revisionist. .. It's easy to throw stones from outside. You could even attend a couple of meetings as an observer. .. I do agree that the long gap between standard revisions is harmful ..

I think the shoe is on the other foot, my "history" is only records such as those at www.j3-fortran.org that show coarrays were on a fairly straight path of being in the Fortran standard even if there were arguments at some point about whether they should be in Part 1 or 4 or a separate TR but which were concluded in 2008 by the then WG5 convenor as "the only way forward".

Anyways the point is not how later individuals can interpret past documents, rather it's the evolution of Fortran.

Given the manner and the pace at which IEC ISO based standard revision work progresses, there is considerable time for compiler implementations to do the background work and preparations they think might be necessary and be ready to implement the feature(s) for their users within a schedule that is competitive with alternate approaches available to users for modern approaches to scientific and technical computing.  Fortran implementations are currently not following such a competitive schedule.

Presently the perception of Fortran by the purse-string holders in many segments of the industry, even for scientific and technical applications, is either that of legacy FORTRAN or too little, too late, that there are far better, more quickly evolving options for modern needs - Fortran is not where they are going to invest.

Consequently it's nearly impossible to get institutional support for standard committee participation, one needs to self-finance, but it's a considerable annual expense one has to incur over several years to make any meaningful impact.  Too few can afford this and I'm clearly not one.

Moreover it is several years of experience a "mere mortal" like me has had where with any inquiry or request, like with the case involving object-oriented programming in the original post of this thread that one might inquire how Fortran language can go beyond the current PRIVATE/PUBLIC attributes in conjunction with the MODULE facilities to meet the needs as expressed by OP here, some Fortran standards committee member or another is sure to "throw cold water" - deflections about timing or use cases or an impact on the type system or semantics or some non-answer or whatever.  It has been a tremendous discouragement, especially with modern programming aspects such as OO.. Then when one says something about the state of affairs, it is not "throwing stones from the outside".