Standardize common tasks even if they are simple to implement

[certik]

A common sentiment against standardizing relatively simple routines for common tasks such as diag (#14), string manipulation such as split (#96) and other similar proposals is that such features are simple for users to implement themselves and as such are not worth putting into the standard.

The counter argument is that if simple things are not standardized, then every user reimplements them in slightly incompatible ways over and over again, and it slows down productivity. As an extreme example, C++ follows this approach also, and did not standardize the syntax for multidimensional arrays (the language itself provides enough primitives for users to implement their own) and as a result C++ has dozens and dozens of incompatible array implementations.

Fortran, unlike C++, has standardized such "simple" things as multidimensional arrays, special functions, and everything else that is needed in practice for numerical computing.

It would be nice to develop general guidelines of what features are worth standardizing and which not, so that we do not need to repeat such arguments in every issue.

[marshallward]

I think my comment in #96 about consideration of a standard library might be more appropriate to raise here.

I know that the C standard library developed more historically than by design, but I think that C's approach has allowed its language to stay compact, while letting libc deal with implementation of tasks such as the ones you describe. I'm not familiar with C++, but it seems like they've also gone in a similar direction.

I could see a standard library also offloading many of these discussions out of the Fortran discussion and into, say, a group devoted to such a library. I could also imagine a standards-defining implementation (glibfort?) alongside vendor implementations, who could focus on optimizations suited for their target platforms.

It could also clarify exactly what can and cannot be done with Fortran itself. If a particular intrinsic cannot be written in Fortran, then it's likely that the language either needs an extension, or is a task that one probably ought not be doing in Fortran.

To address your points, a standard library would help to achieve your goals:

• They would not appear in the standard, nor would the committee need to deliberate over them

• Implementations would vary, but interfaces would not. And in all likelihood there would not be many more implementations than there are compilers.

• A standard library could afford to be more nimble, as one could trial new libraries alongside existing compilers. As it is, there's a big learning curve to add anything to any Fortran compiler.

• It would help to delineate the guidelines that we seek on what ought to be a language feature, an intrinsic, or what should sit in an external library.

I could list the various things that I would like to see in such a library, but I'll hold my tongue for now 😝.

[ivan-pi]

Note that a Fortran processor can provide non-standard intrinsic modules. In principle if these are described accurately enough, other vendors can also implement them. If licensed permissively they may even be inclined to share their implementation.

I just discovered this fact here: https://fortran-lang.discourse.group/t/does-an-intrinsic-module-have-to-be-part-of-the-standard/6555/2

[shahmoradi]

We can similarly argue for even simpler things missing in the language that is so obvious and trivial, yet a constant source of pain and torture, like real numbers are practically universally considered a subset of complex numbers, which means conjg(x) == x should hold if x is of type real or integer rather than throwing a compilation error. Of course, we can take a different route and write a separate module with >10 user-defined functions under a generic interface for such a trivial task and hope for an optimizing compiler to inline, or we can wait another 5-10 years and write a template for this trivial task, or we could have thought (or still think) more carefully about the numeric system and fix such tiny but costly potholes in the generic highway of the Fortran city.

[MPenaR]

Real numbers are not practically universally considered a subset of complex numbers. In many cases, real numbers are considered isomorphic to a subset of the complex numbers. That would mean that conj(x) should not make sense, but there should be easy to perform a casting from real to complex numbers.

[shahmoradi]

or the committee can refocus on what matters practically to BLAS, LAPACK, machine learning numerical libraries, and Fortran practitioners, and learn from other generic numerical computing languages that have grown their community to four times that of Fortran in less than one-fourth of Fortran lifetime by paying more careful attention to what users and ML algorithms need. Coercion to complex, conjugation, and conversion back to real does not seem viable in numerical algebra routines.