Thank you for your efforts, hope there is great success in coming up with simple semantics and simple syntax for Generics, that will be a boon for the language and its practitioners.
Please note it is most disheartening to read "The general sentiment was that phrases/behaviors that are “implied,” “as-if,” or “automatic” are not really “Fortranic.”. Readers will note Fortran will be truly dead in the water without it, the adoption of modern Fortran, as in the changes heralded starting Fortran 90 - would have been negligible without this, the entire edifice would have collapsed. I am so taken aback by this I don’t know if the list is in the right order of conveying the importance, but readers will note:
a module procedure is as if an explicit interface becomes available automatically for USErs
working with objects of ALLOCATABLE objects is as if an automatic garbage collection is taking place,
with a nonpointer actual argument with TARGET, a received argument of POINTER attribute and INTENT(IN) becomes automatically associated with the actual argument,
in the case of a generic-name of an interface body the same as that of a specific procedure, the disambiguation still occurs as if performed automatically based on the rules in the standard,
in the case of a generic-name of an interface body the same as that of a derived type definition, the distinction between variable reference and structure constructor(s) still occurs as if performed automatically based on the rules in the standard,
data initialization using the DATA statement is as if the object is automatically imparted the SAVE attribute,
variable definition in the variable declaration statement is as if the object is automatically imparted the SAVE attribute,
eschewing the => procedure name in derived type definition of a type-bound procedure is as if the procedure name is the binding label
…
These are but a few things which immediately occur to me as I process the above-expressed sentiment, not all are directly relevant in terms of the context here and the desired goal of Generics with simpler semantics and syntax but the sentiment applies.
That is, Fortran ultimately has to be for the practitioners, for simple and efficient practice by them.
While strong concepts, if really done well, can be beneficial for the practitioners of Fortran and which can then imply not a penny less on the part of the effort a practitioner has to occur to define templates, not a penny more too has to come in strongly in the sense a practitioner should not have to expend any extra effort than absolutely necessary to define the template. In the simple case raised by @certik in the GitHub proposal with a generic function, this premise is not being met - hence the concern.
P.S.> @certik ./ any moderator of this Discourse: it might make sense to move all the comments in this thread related to Generics to a separate one, say titled “Simple Generics”?
I moved the comments into a new thread “Simple Generics”.
@FortranFan I think it’s best to prototype and play with actual code and get some experience. Let’s implement the simpler generics for kind as “syntactic sugar” and see. Let’s iterate on the design.
I agree in principle though in practice given the realities of Fortran with its nearly 70 years of legacy, particularly with its standard, one almost two Fortran 2018 conforming processors to prototype.
Does LFortran currently support the following standard-conforming snippet?
module m
interface sub
module procedure sub
end interface
contains
subroutine sub()
print *, "Hello World!"
end subroutine
end module
I do not see a problem with backwards compatibility for this use of the KIND attribute.
Rather, my concern might be that this is similar (almost identical) to the way the KIND attribute is used in parameterized data types (PDT). PDTs were introduced in the language in f2003, and there are even now, 20 years later, major compilers that do not support them, even partially, at a usable level for programmers. Both PDTs and templates for generic programming seem like they would be very useful for programmers, but if the implementation is so difficult that it cannot be done in a practical way, even after 20 years, then perhaps this approach should be discussed from this perspective. Is it some aspect of this KIND attribute that has caused the long delay of PDT implementations?
I think it would be great if there is a centralized thread (in this Discourse, not on Github) that collects such generics-related documents in one place, such that people do not have to search around many places for related information. Then any people can add new links or URL as needed, so it is easy to update / modify the thread. Also, one useful “rule” in that thread may be “no discussion / arguments here”, i.e., the purpose of that thread is limited to just collect the related materials / texts (and possibly cite the key ingredients, as in the above post).
