Functional Programming Addition to stdlib

What are your opinions of adding @milancurcic 's Functional-Fortran library to stdlib? As a functional programming fan and given its benefits in expressing ideas concisely, I am all for it. I think it would be an excellent enhancement.

1 Like

I’m a fan as well but I’m not convinced it’s a good fit, for a reason that I’d concisely express as:

What’s useful is not performant; what’s performant is not useful. :slight_smile:

For example, head, last, init, and tail, as well as recursive stuff like map, filter and fold are useful for a functional style but if you use it you’ll be banished from HPC land. Something about redundant array copies and Fortran compilers not dealing well with many levels of recursion. Maybe it improved since.

Some of it is redundant with F2018 (e.g. use the more Fortrannic [integer ::] instead of empty). Some of it is in stdlib (e.g. arange).

Of the bunch, perhaps map is the best candidate. It does largely what elemental does, but without the restrictions of elemental. Before F2018 that was useful for recursive procedures, but now you can do that. I believe you still can’t pass elemental procedures as procedure pointers. Maybe map could be useful there.

That said, does anybody use this as a dependency? I don’t, but it was a fun exercise.

2 Likes

That is good to know. If in general, the functional implementations in Fortran are not as performant as the non-functional counterparts or implementations, that is understandable.

When declaring a zero-sized integer array named empty I found that [integer ::] was not needed. The declaration

integer empty(0)

was enough, even when it was an actual argument of a subprogram where the dummy argument was intent(in). But I wasn’t trying to declare empty as a parameter, and I would have needed different names for empty arrays of different kinds or ranks. (I had started by trying just [ ] because in mathematics and logic there is only one empty set, but I needed reminding that Fortran arrays are not sets.)