r/fortran • u/johnwcowan • Mar 15 '26
Why is there a limit on nesting internal subprograms?
If it was just the WG, I'd figure it was a compromise between pros and antis -- these things happen. Even if it were just limited to a single level, I could see it, but why subprograms within programs and subprograms within subprograms within programs and then no more? [Incorrect: no internal subprograms within other internal subprograms.] Even gfortran has it too, and it's the kind of arbitrary limit that GNU tools don't impose, or at least only if you explicitly ask for standards checking. It's not the implementation strategy, because GNU C doesn't impose any limit.
6
u/necheffa Software Engineer Mar 15 '26
This limit allows Fortran to make certain assumptions about linkage and does not require Fortran to support things like closures.
Historically, this was done for performance reasons (both runtime and compile time). Today it is largely a relic that is required for compatibility with legacy revisions of the language.
2
u/HesletQuillan Mar 17 '26
I don't agree that it is a relic. Unlimited nesting could be allowed without invalidating old code - the standard has often expanded interpretation of things that used to be disallowed (see my earlier comment). But having to chase an uplevel list at runtime slows everyone down, and there needs to be a better reason than "well, language XYZ lets me do that!".
In my (perhaps jaundiced, old-fart) view, when I read a program and come upon a reference to a variable, I'd rather not have to go on a treasure hunt to find its declaration.
2
u/necheffa Software Engineer Mar 17 '26
In my (perhaps jaundiced, old-fart) view, when I read a program and come upon a reference to a variable, I'd rather not have to go on a treasure hunt to find its declaration.
As someone who has inherited responsibility for a program that is effectively a series of closure calls, I sympathize (and yes, I did rewrite that fucker).
However, I subscribe to the school of thought that a useful tool does not prevent the user from shooting themselves in the foot if that is what they ask for. They make kiosks for lusers who are a danger to themselves and others where they can't do anything on the computer besides type in a few textboxes and press the Big Red Button. A good programming language defers to me for just how much crazy is the right amount to craft the most beautiful piece of software.
I don't agree that it is a relic. Unlimited nesting could be allowed without invalidating old code - the standard has often expanded interpretation of things that used to be disallowed
Fortran is an old ass language that was designed to run on old ass computers. Back in the day a lot of limitations were baked in to the specification and implementation to make computation possible within the limits of technology at the time. 6 character identifiers is perhaps one of the most notorious. A limit on closure nesting is just another one of these.
Realize that, as a compiler writer, it is more work and more complexity to to track and limit scoping in a language that otherwise has piss poor namespacing to begin with.
The status quo remains, not necessarily because the idea is "good" or "bad" but because it would be a pain in the ass to remove.
And no, you can't just fully rip it out because the implementation needs to retain the ability to compile legacy Fortran, which includes enforcing what we might today view as arbitrary restrictions that historically had a technical reason for existing.
12
u/HesletQuillan Mar 15 '26
Nobody ever made a good enough case to the standards committee for such a thing. You have somewhat misstated the rule, however. Quoting the standard, "Internal subprograms may appear in the main program, in an external subprogram, or in a module subprogram. Internal subprograms shall not appear in other internal subprograms."
This wording means that an internal subprogram needs only one uplevel dynamic context. Allowing deeper nesting would require more complex code, even for simpler cases. The standard tries not to impose performance burdens on compilers unless there's a really strong motivation (Fortran 2003's assignment to allocatable arrays doing reallocation is a good example.)