Discuss and possibly change `sp`, `dp`, `qp` kinds constants

[certik]

We have not reached an agreement if we should be using sp, dp, qp or some other names. This is a subset of the issue #25. This current issue is only for the naming convention. Anything else should be discussed in #25.

This is not a pressing issue, as for now use use sp, dp, qp as placeholders to allow us to move on to implement an actual functionality. But we definitely have to reach an agreement before we consider moving from experimental to main.

I was hoping doing a survey of all open source Fortran projects, as well as some closed source that I have access to, and then we'll see what the large community is actually using. Then we can decide what to do.

[certik]

People in #25 who preferred different names than sp, dp and qp are: @jvdp1, @milancurcic, @marshallward. Others seem either fine with it, or not expressed an opinion.

The next candidate seems to be the names from iso_fortran_env, so real32, real64 and real128.

Let's also discuss half precision. The natural names for iso_fortran_env would be real16 (https://github.com/j3-fortran/fortran_proposals/issues/13) and bfloat16 (https://github.com/j3-fortran/fortran_proposals/issues/3).

The shorter names could be hp for half precision. For bfloat16 there does not seem to be an established short name (some candidates could be bp, bfp, ..., but I would maybe just use bfloat16, as I assume it will not be as commonly used in Fortran codes as dp is).

---

To move this forward, how about using a similar multilayered approach as in other issues:

1. The stdlib_kinds module introduces real16, real32, real64, real128 names, the same as in iso_fortran_env.
2. Then it also introduces aliases hp, sp, dp, qp.

And we can use both, say in user codes. Regarding the stdlib code itself, we can use both for now also (depending who submits the code). Later, as we fix #35, and routinely support all integer and real kinds, I think a natural and consistent convention will arise for stdlib, as we gain experience.

@jvdp1, @milancurcic, @marshallward, is that an acceptable compromise?

[jvdp1]

@jvdp1, @milancurcic, @marshallward, is that an acceptable compromise?

I would suggest to use one of the 2, but not both, simply to avoid to go through all the codes in the lib, when a convention will be taken. My preference is still for real16, real32, ... but I would be ok with the other one, especially since stdlib has its own kinds module.

[milancurcic]

I also prefer sp, dp, etc. over having both, which would be confusing to any reader unaware of this discussion.

[marshallward]

I would prefer to not have two sets of naming schemes.

I would also prefer not to just re-use the names from iso_fortran_env and have them point to the contents in iso_fortran_env. I already somewhat consider those "reserved".

As the last ones standing, I guess that I would be fine with sp, dp, qp.

Still not a fan of these, I think short two-letter names are better reserved for scratch variables (e.g. iteration counters) but I would also not wish such concerns to impede progress.

[certik]

Ok then. I am fine with the current scheme also. We can revisit this later. For now I think we can close this issue.