Does anyone know if there’s talks, plans, rumors, or anything that might indicate if Hollerith constants will ever become unsupported in new versions of compilers? I am looking for inspiration to modernize a codebase that makes extensive use of them and knowing their impeding demise would accelerate this.
It’s been a few years since, but at a standards meeting I asked representatives of all the compilers present if they would ever consider removing support for deleted features. (Hollerith constants, of course, are a F66 feature that didn’t even make it into F77.) The answer was universally “No”. From an implementer’s point of view, ripping out support for a language feature is counterproductive, can lead to bugs, and just annoys the users. Of course, I don’t speak for any of the implementers at this point.
That said, I would strongly recommend removing Hollerith constants from your code as newer compilers may choose to not implement them, and several new compilers are under development. They are rather ugly and error-prone, and easily replaced with character literals (unless the code is assigning them to numeric types, in which case you have bigger problems.)
1 Like
Hi,
I am aware of their ugliness and them being error-prone. It’s just that they are key in a very large project and it will take a bit of time to change them. I was looking to see if I could use a lack of support notice to accelerate this.
Thanks for the answer!! have a great rest of whatever time of the day you are in !
I hit the problem of being able to store short strings in numbers yesterday. I inadvertently compared a REAL with a literal string and ifort compiled it without a complaint. I subsequently found it when the program was not behaving as expected. Is is possible to disable this disable this functionality for modern programs?
You cannot disable that feature, but you can enable standards checking (-std) and also tell the compiler to treat nonstandard code as an error (-warn stderrors). The behavior you describe was a common extension in the F66 days (quoted string instead of Hollerith literal.)
1 Like
Thanks Steve. I found myself wanting more type-checking rigor.
A 19-year-old thread from comp.lang.fortran said the tidy program can convert Hollerith constants.
Tidy does convert the Hollerith to character strings, but it leaves
the types of the variables unchanged. It does generate a log file
which can be used to determine which variables need to have their types
changed.
1 Like
When the first Fortran 77 compilers started coming out, being able to use character data type was a breath of fresh air. Just makes code so much easier to develop and maintain.
But I do recall one developer of a fairly large code that was used by a lot of his peers telling me he hoped to retire before he had to fix all the Hollerith stuff… (Among other things, he had a giant blank common of integers which he dynamically sized and filled with data of various types. So there was a lot going on under the surface which was not immediately apparent to anyone not familiar with his coding style.)
IMHO compiler writers who don’t give warning messages about use of obsolete constructs by default are doing their customers a disservice. Provide an explicit option to silence the warnings.
We had many customers who would disagree with you.
I don’t think I understand exactly the sentiment, but if it is “the compiler should shout at you by default if you’re using obsolete constructs” I fully agree, people should be reminded that their code is bad, maybe it will inspire them to change it!
1 Like
Is that because the programmers at an organization need approval to make any changes to their code or even their compiler options? I think there are settings where such changes triggers an expensive validation process.
Quoting from a work by M. Metcalf,
In principle, the transition from FORTRAN 66 to FORTRAN 77 is relatively simple, as backwards compatibility for standard conforming programs is guaranteed by the standard, apart from a number of minor details and two major ones: the elimination of the extended range DO-loop, and the replacement of Hollerith constant data by the CHARACTER data type. This later point has led to some significant problems for some types of code used in high-energy physics programs, particularly as the Hollerith data are often used in argument lists, for examples as histogram titles, and are also often mixed via an EQUIVALENCE statement with numeric data, for example in I/O buffers.
[1] Metcalf, M. (1982). FORTRAN is alive and well (No. CERN–82-12).
1 Like
This is a long standing issue what the default options should be, there are two camps:
- The default should be the standard, possibly also some or all extensions, no warnings; you can enable warnings with a compiler option. I think these are the customers that Steve mentioned.
- The default should give good warnings and error messages for obsolete and not recommended features; you can disable those with a compiler option. I think you belong into this camp.
Both are self-consistent and valid and there are cases where you would prefer one over the other. I think a good compromise is to have a single option that can select between these two modes. Most compilers choose the first mode. LFortran chooses the second mode, for example implicit typing is disabled by default. This is for a longer discussion why I think the second mode should be on by default, and I am happy to have it with anybody who disagrees, ideally over video.
Regarding Hollerith constants, LFortran currently doesn’t support it, but it has been requested by our users and we’ll have to implement it eventually: Implement Hollerith constants (tokenizer error: Token '.' is not recognized) · Issue #1645 · lfortran/lfortran · GitHub. But you’ll get some nice warning if you use it by default. 
2 Likes
As I see it, the compiler should have its own standard (e.g., GNU), so no warnings except when asked to strictly adhere to a specific ISO standard.
Your comment suggests that LFortran is, in fact, using its own standard.
1 Like
Yes. You can switch standards with the --std option:
--std TEXT Select standard conformance (lf, f23, legacy)
2 Likes
I am a fan of the compiler reminding me I did stupid things it has saved me more times than it has caused me grief.
LFortran chooses the second mode, for example implicit typing is disabled by default.
I love this, I work in an app that has a lot of implicit typing and I am trying to fix things one at a time. I tried compiling our app with lfortran and quickly realized that the standard is that and that there are no holleriths! haha
3 Likes
I hadn’t seen this response before I made mine. Guess we hit “Reply” about the same time.
On that comp.lang.fortran thread, I made a couple of long replies to Lynn McGuire on the topic. Re-reading it, my suggestions would be pretty much the same today. Did that code ever get running on a newer compiler? Or are they still stuck on Watcom? I stopped regularly reading comp.lang.fortran not long after that.
That code illustrates the fallacy of ignoring the problem, or claiming you didn’t know you had one because the compiler didn’t bother to tell you about it, until it is way too late. The alternative to the Hollerith stuff was available 40+ years ago. That is plenty of time to update any code base. (Unless you are someone like google - who has literally billions of lines of code floating around in their source code control system. But none of it, I’d imagine, is written in Fortran 66.)
Sometimes as a hobby it is fun to grab some ancient code and try to get it running on a modern system. I don’t have a problem with adding some sort of -legacy compiler option to get it to compile. But on Real Code that is going to be used for Real Things that I get Paid For, I want it to be clean with all the compiler checking I can get - with preferably zero options needed. The earlier a problem gets discovered, the less expensive it is to fix it.
1 Like
Penny-wise and pound foolish, in my opinion.
1 Like
Please take your time to implement modern features first. That should keep you busy for the foreseeable future. 
I also like the idea of making implicit none the default! Guess I need to get LFortran running on my system…
1 Like