Thank you @everythingfunctional for taking the time to read our paper, and for providing your extensive list of notes. I’ll have to split my reply into two installments, both because this post with the bulk of my comments is going to get already very long, and because I am preparing for travel and a longer absence. My second post with the code examples that you requested may thus take longer.
I presume this is referring to our choice of providing parameterized (generic) methods, rather than parameterizing the interfaces/traits themselves. We had internal discussions on which of the two to prefer, and implementation considerations played a significant role in these discussions. We nevertheless decided to give parameterized methods a chance in a future LFortran prototype implementation (and to keep parameterized interfaces/traits as a fall-back option) because they significantly simplify user code (as it is shown in our paper).
We made this decision being aware of such methods having been implemented successfully in at least one mainstream language before, namely in Swift. This was sufficient practical proof for us, that parameterized methods can be implemented efficiently.
Not being a compiler developer, I do not know how this is actually accomplished in Swift. If @clattner_llvm is still following this discussion thread we all might get lucky, and get an answer to this question. I strongly doubt that he, and all the other Swift developers, would have chosen to implement parameterized methods, in particular in a language which is called Swift, if their performance was “terrible”, as it is theorized above. The proof is in the pudding. That is, in an actual implementation.
A significant number of language developers quite obviously disagrees with these statements. Type extension “mixed” (as it was called above) with interfaces (or protocols/traits) has been the main object-oriented programming paradigm since the 1990ies, namely in Objective C, Java, C#, D, etc., and more recently in Swift, which adds to these capabilities retroactive implementation of protocols.
As @clattner_llvm informed us up-thread, these features will also be supported in Mojo. Millions of programmers are using these features every day. So I’d recommend to everyone who is interested, to have a look into the documentation of these languages, and to try out these features for themselves using the compilers of these languages, in order to learn how all of this works in practice.
If one nevertheless doesn’t wish to go through the trouble of having to support such interoperability in Fortran, then there’s always the possibility to declare type extension obsolescent, and to have it replaced in the long-term by a pure traits based OO-model as it is supported in Go or Rust. This would simplify the language a lot. It would also not be the first time in Fortran’s history that a feature is declared obsolescent relatively shortly after its introduction (see the “forall” statement).
None of these statements is valid.
Traits are contracts. As such, they enable easy conformance to the Liskov Substitution Principle (LSP, which is a form of design by contract). If an OO code conforms to this principle, then it doesn’t need to make use of any run-time type-inspections (RTTIs). So by using traits to express run-time polymorphism, one completely avoids RTTIs, and hence obtains run-time polymorphism of maximum performance.
The situation is reversed if implementation inheritance and inheritance hierarchies are used. In this case, violations of the LSP are essentially unavoidable. Which is the reason why one needs to use those pesky “select type” (RTTI) statements in Fortran, that drag down run-time polymorphism’s performance. So the above statements are wrong. The reverse is true: Traits improve polymorphic code performance!
The argument regarding v-tables is a poor one. In HPC codes, a trait object will be typically initialized only once (during the code’s initialization phase) at run-time, by calling the constructor of some class/type. Upon initialization, the constructor will automatically load the class’s v-table into the object, so that from then on the run-time system of the language can route any polymorphic calls to the functions of that class. This is hardly slower than static dispatch. It typically requires only some additional function pointer evaluation. There’s no reflection/introspection involved.
The “feasibility of implementation in Fortran” argument is equally poor. In an “apples to apples” (i.e. single to single, and multiple to multiple) inheritance comparison, interface inheritance is conceptually simpler, and hence easier to implement, than implementation inheritance.
C++ has multiple implementation inheritance, and it is well known how to implement this in compilers. Supporting multiple interface inheritance in Fortran will thus be even simpler than that.
I will respond to this and your next item, using some actual code examples, in a separate later post – as already mentioned above.
See my reply to your previous item.
I presume what is meant by “third party types” is user-defined types (i.e. derived types in Fortran). Type sets, the way they are implemented in Go, accept also user-defined types. I’d recommend to read the link to Ian Lance Taylor’s work, that is cited in our paper, to learn which capabilities the Go developers intend to support through this feature in the future.
The statement that “this feature is effectively already handled by the Japanese generic procedures proposal” is of no relevance in the present context, because the cited Japanese proposal doesn’t address the other issues that are addressed in our paper.
The syntax, that we employ, pretty much mimics that which is used by Go and Swift, and judging from almost all other reactions in this thread, Fortran users appear to find it quite easy to follow and to understand. Regarding the comment on type extension, I can only reiterate my recommendation to everyone interested in the topic to consult Swift’s documentation.
I will refer back to my answer to the preceding item, noting that others in this thread, again, had no trouble.
It seems that many of the points, that I addressed above, stem from some general unfamiliarity with object-oriented programming languages or concepts, and some unexplainable, if not unbecoming, expectation towards the three of us to provide a document at the level of a technical specification, that contains even the most minute details of every single feature under consideration. What we decided to make kindly available here is a whitepaper, as it was correctly called up-thread.
Initially, this paper was intended for internal use, so one of its purposes still is to serve as a memo for ourselves, of the capabilities that are present in other programming languages. Some of these capabilities were already emphasized in an earlier thread here, along with a number of corresponding suggestions, that we made sure to follow, but which otherwise seem to have been completely forgotten!
I will finally add that we are excited that Ondrej Certik plans to prototype this entire proposal in an actual compiler, to iron out all the details, and ideally we’d like to have available more than one such compiler implementation.
PS: It seems that for some reason I can only cite two users in the same post, which garbled the initial formatting of this post. The admins might want to give this a look, as to why that happens.