Template programming

[wadudmiah]

edit by @szaghi

Discussion about Template programming started into issue 2 and continued here for the sake of clarity.

[zbeekman]

I was opening the same issue right as you posted this one. Here is what I had to say:

This is a place to discuss templating as a new/additional Fortran language feature, rather than issue #2, which is a more procedural discussion about how to adequately document proposed language features.

I personally think this has been hashed out many times in the past, and that there are some very serious drawbacks to the notion of templating, including combinatorial explosion of generated code, incomprehensible error messages, and hindering compiler optimizations, to name a few. I think there are better alternative approaches to generic programming, but wanted to open this issue since it was brought up by @wadudmiah on #2 and I am certainly open to hearing other peoples opinions, suggestions, concerns etc.

[szaghi]

For the sake of convenience, I repeat here the comments of @wadudmiah and @tclune contained into issue 2

@wadudmiah said

How would you vectorise templated operations? From what I understand, widths of data types can only be determined at runtime or is this not the case? If templated operations can be vectorised, then this will definitely be a useful feature to have. A templated BLAS library could be written!

@tclune commented

With regard to templates in the language ... types would not be determined at run time. Everything must be resolved by the time the executable is created. I believe that the approach in C++, is that a great deal of compilation is actually deferred until link time when the needed types are known.

My experience about templating is nearly zero, thus I cannot add any useful comments. Anyhow, I recently read about a Van Snyder's proposal about parametrized module that sounds very very interesting for achieving generic programming.

My best regards.

[wadudmiah]

@zbeekman I totally agree that there are issues with templated programming and you have listed some good points. With regards to compiler optimisations, I didn't think the compiler will be able to vectorise operations unless it re-compiles the code to determine the width of the data types.

[cmacmackin]

I haven't used C++ so I don't know for certain, but I think templating is a purely compile-time feature. The compiler will only create versions of types/procedures needed at compile time. For libraries, this means that you must either specify in advance which types you want to pass to your generics or you put all template code in the header files. The compiler will always know what types a given routine will work with, so it shouldn't present any problem to compiling or optimisation. However, it can lead to very long compile times.

I'm interested to know what @zbeekman means in terms of better approaches to generic programming. I'm not aware of any approaches other than something like templates. Modern compilers can certainly work to minimise some of the concerns about how long it takes to compile. The nim language offers some superb generic programming features (including ways to constrain types) which, among other things, help to ensure better error messages. Its compiler is very fast. However, that compiler manages things like dependency resolution to help with this and I don't think all of the same tricks would be possible with GCC.

[wadudmiah]

I don't think the Fortran standard would dictate whether this is a compile time feature or not. This would be left to the compiler/runtime system.

[cmacmackin]

I agree, the standard wouldn't dictate that, but that's how templates are typically implemented.

…

On 26/07/17 12:27, Wadud Miah wrote: I don't think the Fortran standard would dictate whether this is a compile time feature or not. This would be left to the compiler/runtime system. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#13 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHxJPcPTH719gSVfW_0hhWLMNUXkJq8tks5sR2jvgaJpZM4OkC9F>.

-- Chris MacMackin cmacmackin.github.io <http://cmacmackin.github.io>

[wadudmiah]

I guess we will be at the mercy of compiler vendors then :-( I'm sure the Intel compiler will ensure it is resolved at compile time as they are very keen on vectorisation - not sure about gfortran.

[cmacmackin]

The approach I describe is how g++ does it, so I'm pretty sure that's how they'd do it. Compile-time resolution would be the simpler approach to implement, too.

…

On 26/07/17 12:32, Wadud Miah wrote: I guess we will be at the mercy of compiler vendors then :-( I'm sure the Intel compiler will ensure it is resolved at compile time as they are very keen on vectorisation - not sure about gfortran. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#13 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHxJPW92VunOEP_8RZfmxGfSSA_GP5IBks5sR2owgaJpZM4OkC9F>.

-- Chris MacMackin cmacmackin.github.io <http://cmacmackin.github.io>

[zbeekman]

Chris, I'm having trouble locating the link and recalling the details, but some time ago I saw a design pattern that was an effective replacement for templating in C++ that was performant and avoided many of the cons of templating. I'll keep searching for it. On Wed, Jul 26, 2017 at 12:28 PM Chris MacMackin <notifications@github.com> wrote:

…

I agree, the standard wouldn't dictate that, but that's how templates are typically implemented. On 26/07/17 12:27, Wadud Miah wrote: > > I don't think the Fortran standard would dictate whether this is a > compile time feature or not. This would be left to the > compiler/runtime system. > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub > < #13 (comment)>, > or mute the thread > < https://github.com/notifications/unsubscribe-auth/AHxJPcPTH719gSVfW_0hhWLMNUXkJq8tks5sR2jvgaJpZM4OkC9F >. > -- Chris MacMackin cmacmackin.github.io <http://cmacmackin.github.io> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#13 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAREPOyaTHBCq7HNr_vdFN8xyBdc5lxfks5sR2kigaJpZM4OkC9F> .

[milancurcic]

When I was implementing the boilerplate nightmare of specific procedures in functional-fortran, I was very close to writing a template preprocessor/transpiler. I was good enough with vim to do this manually so it didn't get to that.

Useful things like templates or anonymous functions could be implemented as a preprocessor/transpiler.

[zbeekman]

Yes templates and anonymous functions could be implemented as a preprocessor or transpiler, but without standardization they will never be widely accepted, and won't be portable when they are used. Indeed many projects have attempted this, but few have gained much use or popularity. And without even a standardize preprocessor, this is quite a problem. If there was a standard Fortran preprocessor, then the user/programmer could implement some of these capabilities themselves. So, IMO, you need some form of templating in the language, or some other means to achieve similar functionality added to the standard or at least some viable alternative to be standardize, i.e., a preprocessor.

…

On Wed, Jul 26, 2017 at 12:36 PM Milan Curcic ***@***.***> wrote: When I was implementing the boilerplate nightmare of specific procedures in functional-fortran, I was very close to writing a template preprocessor/transpiler. I was good enough with vim to do this manually so it didn't get to that. Useful things like templates or anonymous functions could be implemented as a preprocessor/transpiler. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#13 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAREPBDFMz_qETaYNFq3UD4_p7CQFAx7ks5sR2sKgaJpZM4OkC9F> .

[szaghi]

@zbeekman

So, IMO, you need some form of templating in the language, or some other means to achieve similar functionality added to the standard or at least some viable alternative to be standardize, i.e., a preprocessor.

What about the parametrized module proposed by Van Snyder? I do not know its details, but it sounds promising...