Since Fortran does not define the preprocessor as part of its Standard, are there known preprocessors that support capitalised preprocessing directives e.g. #INCLUDE "some file" or #DEFINE SOME_VAR` or is that something that is generally seen as a bad idea?
Using all uppercase for macros and lower case for normal fortran variables and keywords is a common convention.
When doing linear algebra programming, one convention is to use upper case for matrices and lower case for vectors. These typically are one-character variables, so there is only a minor conflict with the preprocessor macros, which are usually longer.
For macro variables, I tend to resort to capitalised names for things. I was more curious with respect to the preprocessor syntax itself, e.g. #DEFINE vs #define, #INCLUDE vs #include, #ELIF vs #elif.
In C and C++ these directives must be lowercase as stated in their respective Standards (I don’t have the references handy), but since the Fortran preprocessor is not standardised something like #DEFINE should be possible. I have never seen a code that does that, but I think some compiler preprocessors support it. I am just wondering if it is worth extending the existing fortls preprocessing capabilities to capture these cases.
In the standards committee, and the JoR (Journal of Record) subgroup, there has been quite a bit of discussion about the proposed Fortran 202y preprocessor and case insensitivity.
I’ve been a minority of 1 in wishing that the standardized preprocessor be case-insensitive, especially with respect to macro recognition and expansion. It feels more in keeping with the rest of the language.
However, there is much concern about existing codes that might be relying on the case-sensitivity of the existing preprocessor implementations. I don’t know yet what the impacts are from examining my library of existing programs. But there are specific examples people have pointed out where existing code would break.
I don’t recall a discussion about the directives being case-insensitive. I can try to look through my example programs to see if it ever shows up in the real world.
Long ago the prep(1) preprocessor and at least two generators of predecessors were made case-insensitive accept for literal strings; which is much more compatible with Fortran in my opinion that cpp or fpp/m4/… . It has been mentioned to be multiple times that it helps prevent problems instead of it being one.
I cannot think of a language that emerged since lowercase was commonly available that is case-insensitive; but I prefer the language being case-insensitive – and as long as it is it seems logical the preprocessing directives also should be. So I am surprised the committee majority thinks it should be case-sensitive. Interesting
Coincidentally I just used prep(1) as a test in the test fpm(1) repository just a few minutes ago. It is normally at
I was also just trying prep(1) as an optional preprocessor in fpm(1) and it looks like most of the fpm(1) options are not working yet? If a standard preprocessor emerges it would be nice to use it immediately with fpm(1) without waiting for it to be built in to all compilers; but so far it looks like fpm(1) would not make that as trivial as I thought it would be with the pre-processor configuration options described.
Much of the standardization work in the committee is to make normative the behaviors seen in existing implementations (as opposed to new language feature design). The preprocessor work falls into that former category.
A case can be made that when we standardize something, we can define new semantics that aren’t entirely backwards-compatible with existing implementations. But potentially breaking existing (working) codes is really frowned upon.
I think this is a correct assessment of the current situation.
The fortran committee should have standardized a preprocessor in the 1980s, but they didn’t, so the de facto standard since that time has been the C preprocessor. C is, of course, case sensitive, so it makes perfect sense for its standard preprocessor to also be case sensitive.
in the case of the preprocessor that argument does not apply unless the preprocessors collide. The prep(1) preprocessor is an example of that. A file can contain prep(1) and cpp(1) directives with no collisions. The use of cpp(1) and fpp(1) can therefore continue so current use is not affected. cpp(1) is needed for many C codes even today even though the use is waining with C++. So there is nothing preventing prep(1) and cpp(1) both appearing in the same file. Previously COCO did that with the added benefit of being reversible. So that is not a valid argument (but perhaps a strong one) unless the goal is to make a processor as familiar to cpp(1) as possible (which will therefore collide with cpp(1)) because cpp(1) has become the defacto one and you therefore want something very like it. But cpp(1) has a lot of
limitations if features are not added – such as templating and looping and block commenting.
I understand the inclination to re-create cpp(1) because of the long if somewhat forced relationship with Fortran That unfamiliar feeling was the primary reason I did not use COCO. It felt alien and was not quickly adapted by vendors so I had to build it or move it to each platform; and I had memorized cpp(1) syntax long ago and it was on any platform that had C (which was essentially no one until Unix caught on, but that is another story).
Whatever is developed needs to be easily available (as an fpm(1) package?) and quickly included in vendor distributions or about the only thing that will be accepted is a clone or upward-compatible superset of cpp. Better than nothing but not by much, I suppose.
Since Fortran also has no standard documentation format the ideal solution would resolve that issue as well. Ford and Doxygen seem to slowly be filling that void; but I would really like a new preprocessor to allow code to be defined between '''fortran and ``` lines and support Discourse Markdown myself.