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

[fortran-lang]

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

[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 (j3-fortran/fortran_proposals#13) and bfloat16 (j3-fortran/fortran_proposals#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.