On backward compatibility #79
Comments
|
As a former vendor, I can say with authority that paying customers blame the vendor when their existing code breaks due to a change. Rather than fix their code, they want a switch to revert to the old behavior. If the existing code was non-conforming, I have little sympathy, but the cases where a standard change breaks code are rare. Most of the cases mentioned in the text you quote are where the earlier standard was silent about some combination of uses. Changing the kind that an intrinsic returns, as has been suggested in #72 , would break code that used these intrinsics as actual arguments. Registry of code libraries is a non-starter. Keep in mind that the usages you see are like the part of an iceberg above water - the vast majority of code is kept privately by organizations loathe to make changes. Whether you like it or not, a major strength of Fortran is that, by and large, standard revisions have not broken existing code bases, allowing the vast extent of code libraries to continue to be used. |
|
Thanks @FortranFan for opening an issue for this. Thanks @sblionel for your comment. I agree with it. What we can do is to write up what we mean by "backwards compatibility" in some document here in the repository, so that new proposals can check against it that they are not breaking it. |
|
I guess here we go back to the idea of Fortran testsuite #57 (although huge
organizational effort and workforce needed to construct) where most usual
applications and usage patterns for constructs can be used, and whatever
breaks it is considered backwards incompatible. As I said in another
thread, the example of "using as actual argument" given by @sblionel is
quite fair and I agree with it. Using size(x) as an actual argument is not
an inherently bad coding practice. But I can also totally see how some
other good and highly beneficial proposition could be rejected just because
somebody found one exotic combination of common blocks, namelists and
equivalences that standard permitted even if it was objectively bad
programming and affected only one code. Are "losses vs benefits" weighted
in that case?
Are *obsolescent* features still the subject of backwards compatibility
considerations? I understand that *deleted* features are not?
wt., 12 lis 2019 o 18:58 Ondřej Čertík <notifications@github.com>
napisał(a):
… Thanks @FortranFan <https://github.com/FortranFan> for opening an issue
for this. Thanks @sblionel <https://github.com/sblionel> for your
comment. I agree with it.
What we can do is to write up what we mean by "backwards compatibility" in
some document here in the repository, so that new proposals can check
against it that they are not breaking it.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#79?email_source=notifications&email_token=AC4NA3K3CMTCGGKJ7IAEJPLQTLVEBA5CNFSM4JMGYGLKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOED3FKBA#issuecomment-553014532>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AC4NA3LW7UT7YUX5L3XOQTLQTLVEBANCNFSM4JMGYGLA>
.
|
|
Older codes should compile and execute without change with newer compilers, possibly implementing new editions of a language standard, everything else being equal. That latter part is important. Sometimes target architectures differ from each other or evolve in place in ways that require some porting of codes. In those situations, compilers (especially from hardware vendors) are going to want to ease the porting, and the standard should assist both coders and implementors with features that maximize and maintain portability. Here's a specific example. Let's say that Big DOE Lab has a code that runs great on 32-bit x86 systems. When recompiled with a new compiler for 32-bit x86, it should just work, everything else being equal. And maybe that's enough for that code & customer. When recompiled for 64-bit x86 targets, if that's desired, it'll probably need some porting so that the larger address space can be exploited to serve larger sets of data. What features make that porting effort easiest on the customer? That's the question that should be driving the designs and standards. |
|
See this observation re: implied SAVE: #40 (comment). So as brought up by @gronki , how are the pros of a change to be weighed against the cons which favor status quo on an issue? |
|
#83 suggests a new keyword to work around certain issues pertaining to backward compatibility. |
|
Implicit typing (#90) can impact a new facility in a subtle way - see #57 (comment). Processors can get the details wrong which negatively impact users in terms of time and lost productivity or worse. And many a user does find the whole notion with implicit typing in Fortran very confusing which further affects the adoption of the language. Modern programming languages try to be rigorously type-safe and/or dynamically-typed. But implicit typing is something almost all of them avoid. But Fortran can choose to ignore the gathering wisdom of modern practitioners and continue to supporting IMPLICIT statements where, users can use such a facility to introduce implicit typing in their scopes and be responsible for their actions. But what is pernicious is the continued support for implicit typing in Fortran as the **default**. Then to expect any and all users to circumvent such a default only by introducing "IMPLICIT NONE" in all their scopes is truly "cruel and unusual punishment". It's one aspect that this language needs to shed - pronto. |
|
I believe that while backwards compatibility is desirable in language development, it should not be a primary value, and should not prevent truly useful features from being added to the language. I believe a significant reason that people choose languages other than Fortran for new work, even in scientific and engineering applications, is because those other languages have features which enable one to write safer, more maintainable, easier to understand code with less effort. In fact, organizations are encouraged to keep their code bases more maintainable and ensure continuity of knowledge because of the occasional breaking changes that occur in those languages. It seems a lack of backwards compatibility can actually be a virtuous cycle keeping your users in a better position. I fear that Fortran's commitment to backwards compatibility at (practically) any cost has actually lead its users down a dangerous path to a precarious position. Eventually one of two things will happen:
In my opinion, the sooner this happens the better, because it will only cost more the longer we wait. It's like continuing to spend on a credit card while only making the minimum payments. Eventually the introductory rate runs out or you hit your limit and you're really up a creek. Better to stop digging and take your lumps now. |
|
@FortranFan, @everythingfunctional it seems based on the feedback at this repository that the vast majority of the outside community agrees with your comments. When I talk to other Fortran developers, I do not see any strong opposition either to new features and even breaking features as long as old code does not just suddenly start breaking. In other words, as long as there is a path how to keep old code working without modifications, but new code can use breaking changes, it seems the community will be on board. Whether this is done with a new language keyword (#83) or some other way. The best way forward is to have a serious discussion about this at the Committee meeting. And until then, @FortranFan, @everythingfunctional, do you want to help prepare some proposals for this? They do not have to be completely formal proposals that will get submitted, but it would help guide the discussion at the Committee if we have some documents in hand showing a way forward. It seems there are several ways, so it would be nice to have a document for #83, and another one for let's say the implicit save #40 with the |
I don't understand this. If old code works without modification, the changes aren't breaking (by definition).
My understanding of the language keyword proposal is that it is a backward-compatible way to change default behavior. |
There are people on the Committee as well as some in the wider community that are opposed to this, as you can read in responses at #83 or #40. The reason they are opposed to it is that if you enable the modern feature (even if it is opt-in) for old code, the old code will break (for example if an implicit |
|
As @tskeith said, an opt-in requirement for new features is backwards compatible. I think that having new features be opt-in is the right approach in the near term, but it is still only a stop-gap measure. We need a long term strategy to eventually get to a point where the committee can at least entertain the idea of proposals that are not backwards compatible. Eventually we will need a change to the standard that will make old code no longer valid, and it shouldn't be DOA just because it's not backwards compatible. Maybe we never get there and it will never be needed, but we should be heading in that direction. The whole point of software is being able to easily modify the behavior of the machine. If you can't change your software, it's already broken, whether you realize it or not. And the committee should stop enabling people to hide from it indefinitely. |
|
What cannot happen is a silent change to the meaning of an unmodified existing program that works today. |
Can you give an example how exactly what that work? For example in the context of #83? Essentially the opt-in "edition" keyword would then become the default (with the latest edition), which would make old code to not work anymore? But one could put "edition F2003" into old code, and it would still work? (Or are you proposing that there literally would be no way to make old code work at all? I think that would not be a good idea.) |
|
My thought is the progression would go something like this:
At that point compilers aren't required to drop support, and you could of course continue to use older versions of compilers, but some old code would no longer be considered standards compliant. So long as you give enough time, and are vocal and public about it, I don't see why this would be an unreasonable path. |
|
Existing code must continue to work unchanged with new revisions of the standard and new versions of compilers unless there's extraordinarily compelling reasons; no serious examples of such have arisen in these discussions. Barring the introduction of zero-trip |
|
@klausler , It's been asked plenty of times if it would be possible to remove implicit typing and implicit save from the language. I think they should, and so do many others. Maybe not for 202X, or even 202Y, but maybe by 203Z if you put If we continue to treat that as a breaking change, and
then it can never be done. The "yeah, that'd be nice, but it breaks code written to the Fortran 77 standard so we won't even entertain it" is hindering progress and killing the language. |
If you are modifying a program to add a version marker, then it is no longer unchanged existing code.
Nonsense. |
|
@klausler please try to understand @everythingfunctional's point of view, even if you disagree with it. In particular, please try to explain your position instead of just saying "nonsense", in order to move the discussion forward. |
Then I think we agree, and my proposed path forward would be acceptable to you, provided we never actually got to the point of dropping the requirement for supporting old standards, which I admit may never be necessary or desired. But I have gotten the impression from mentions of old discussions that not everyone agrees with that stance. I got the feeling that some proposals were rejected in the past, even though they were opt-in, because "adding that one line changed the meaning of old code". Unless I'm mistaken, which I admit I may be, I don't think it is "Nonsense". |
|
@everythingfunctional let's talk about your proposal at #79 (comment) some more. It seems it actually satisfies what @klausler wants. For example, for current (old) code, if the version specifier is not specified, then the standard can say that it means the code implicitly assumes Fortran 202X. If you want to use features from a later Fortran standard (say 202Y), you have to put the version specifier in, such as "edition Fortran 202Y". However, the minute you put in "edition Fortran 202Y", it can break the code (say implicit save becomes implicit init). This proposal has the following features:
|
|
I'm in favor of backward compatibility so I support points 1. and 2. here. Point 3. is okay if not implemented in the standard, or if implemented as "the compiler should warn that edition is not specified". In general, I think it's okay to consider new language-breaking features if the benefits clearly outweigh the costs. I haven't seen such proposals so far. |
|
Version specifiers must not silently change the meaning of code. It's okay if they cause existing code to begin to elicit new error messages (e.g., they imply new checks akin to Requiring a version number to appear in the program at some point in the future would cause unmodified existing code to stop working. |
|
@certik , I am in favor that, of course so long as there is nothing in 202X that would be "breaking", but I believe that has already been determined. |
You should have seen the first draft of that word. The claim that 'The "yeah, that'd be nice, but it breaks code written to the Fortran 77 standard so we won't even entertain it" is hindering progress and killing the language.' is hyperbolic and unsupported by evidence. The single example of a feature on this site that would have been a breaking change was a profoundly bad idea anyway (viz., allowing new enumeration names to stand alone as statements without keywords, so |
I think this would forever require Fortran to carry around the baggage of its past mistakes. One would not be able to make a new proposal without first considering all of the possible implications to all prior versions of the language. Of course it wouldn't be a good idea to have silent changes between consecutive versions, but to never be able to change the meaning of old code?
Your test suite I would expect. If we're never going to expect our users to start using modern software development practices, who are we modernizing the language for? |
That is a good thing. |
There are multiple examples of breaking changes being proposed in this repo. Not the least of which are removing implicit typing and implicit |
I disagree. There are multiple pushes to encourage the committee to move faster. But if after every revision we now have to consider the sum total of all the revisions before the next one can be released, the cycles will take longer and longer, and we'll never be able to go faster. |
I agree with @everythingfunctional. And I do NOT AT ALL think deletions are "silent changes". And I do NOT think "One would not be able to make a new proposal without first considering all of the possible implications to all prior versions of the language" is a "good thing" at all. Deleting "implicit typing as the default" and deleting "implied SAVE" in a future standard revision will in all likelihood be received far more positively than the 8 deletions already in the standard (c.f. Section B). For example, a code such as I = 42
ENDcan be allowed to be rejected by a future processor. By the way, every "legacy" code I have seen either already has "IMPLICIT NONE" (which was the most commonly used non-standard extension prior to Fortran 90) or "IMPLICIT INTEGER(I-N), XXX(A-H,O-Z)" (where XXX is REAL*N or DOUBLE PRECISION, etc.) and none of such code will be impacted by the deletion of "implicit typing as the default". Similarly, a code such as INTEGER FUNCTION COUNTR()
LOGICAL FIRST = .TRUE.
IF (FIRST) THEN
COUNTR = 1
FIRST = .FALSE.
ELSE
COUNTR = COUNTR+ 1
END IF
ENDcan be allowed to be rejected by a future processor. But should the code have SAVE specification in some form (e.g., SAVE statement and/or LOGICAL, SAVE :: FIRST = .TRUE.), then deletion of "implied SAVE" will have no impact. Moreover, if "implied SAVE" is deleted and processors support such a change by default, quite a few purse-string holders I know will only be happy and start to view Fortran a little more positively. Note it's already the silent introduction of vulnerabilities in code such as via "implicit typing" and "implied SAVE" that bothers many a manager. |
|
@certik wrote:
@certik , please note what I've been suggesting is only for "implied SAVE" to be deleted, not that "implied SAVE" becomes "implicit My own suggestion, as I've mentioned in other issue threads, is for no more "implicit" semantics.
|
|
@FortranFan regarding your last comment, yes, that is the minimal proposal that we seem to get an agreement in #40. I plan to write it up soon. (Yes, I do think we want more, but we do not have an agreement on that.) @klausler yes I agree @everythingfunctional could have formulated it better also. Thank you for explaining it. |
|
Sorry for being inactive in this board for a longer while.
Can I ask those who are familiar with arguments that are actually held by
the standarization entity: what is actually the reason behind absolutely
strict preservation of backward compatibility in some cases (such as:
making implicit none as default) and less strict in other cases (some
features *have* been deleted from the language). As far as I understand,
99% of the codes would not have issue with introducing one line of code
that re-enables some obsolete features. If for some reason this is not
possible, the remaining 1% can use compiler switches that compiler vendors
will certainly provide. I do not understand how holding back the
development of the language is in any way explained by few codes that could
potentially require re-certification.
I feel the "backwards compatibility" argument is used very inconsistetnly
and only where it is convenient and the supposed penalty for doing that is
highly exaggerated. After all, it's not the language gets obsolete every 5
years: it is literally two or three features to be deleted that actually
that recur in every discussion and that do hold back the language. And none
of the proposals change silently the behavior of the language but they are
better characterized by "hardening" or making code "strict".
I think there should be only one Fortran, the current one. It can still
benefit from the power of legacy of F77 codebase, but I feel this argument
is often exaggerated and overused to prevent good change from happening. I,
personally, would be happy with "strict" or "hardened" or "explicit" or
"modern" keyword as a middle ground that disables all terrible features
without having to write 10 lines like "implicit this" and "explicit that"
and that would also make backwards compatiblity a non-issue (if you use
"strict", you keep code up to date cause it might become obsolete according
to the the future revisions of the standard, if not, don't include it and
you're good for the next 50 years).
… |
|
@gronki thank you for explaining your position. Your last comment is what I believe also that we should do. (I thought previously you were against doing what you just wrote.) @sblionel you are the most prominent person on the Committee that is active here, what do you think? This is something I would like to discuss informally in person at our next meeting to see what others on the Committee think. |
|
@certik , I have already suggested to Dan Nagle that we spend a few minutes at the next meeting to discuss the general issue of backwards compatibility. I've written some on this topic already, but here are some more thoughts...
I do not agree with those who argue that backwards compatibility prevents new features from being added. As I have already written, it can affect how we specify the new feature. Last, I'm puzzled and disappointed at all the energy being devoted to this general topic, which I view as being a silly hill to die on. But I'm done here and will be interested in what J3 folk have to say about it next month. |
|
@sblionel thank you for the feedback, I really appreciate it. Let's discuss more at the meeting. |
Can anyone please post here some basic information (name, domain, etc.) on FORTRAN codes making use of implicit typing that are in "production" use? Also, the ones which may have constraints such as software recertification? |
|
As implied in my #83 (comment), my impression remains the use of implied SAVE as deliberate intent that is part and parcel of code design is absent in codebases developed using facilities introduced with Fortran 90 and later standard revisions. An improvement in Fortran which forces explicitness in terms of SAVE attribute (thus no implied SAVE) will be a tremendous blessing that helps many a codebase rather than prove detrimental. |
|
At the upcoming Committee meeting I would like us to
Then that would put the conclusion to this debate. But until we do that, we are not done here. |
|
The change to NAMELIST in #67 is another situation (#67 (comment)) where backward compatibility is also of concern, "Changing the default behavior of namelist will change the behavior of existing programs. This may be done only for a very important reason, and a convenience issue, such as a default setting, likely does not rise to that level.. I do find the concern in this case rather odd because
So to do something here to improve the default behavior appears more beneficial overall (that may also make the practitioners employ the corrected NAMELIST facility more) than any cost due to a "breaking" change or by not doing anything. |
|
Backward compatibility was a concern on the NAMELIST change, sure, but more important was that the desired behavior could be easily obtained with already existing features, such as adding DELIM= on the OPEN, READ and/or WRITE. We’re generally disinclined to add “yet another way” to so something, and even less so to force a behavior that some might not want. I’d also note that list-directed I/O is a place where you probably would not want this, and a blanket ignoring DELIM-‘NONE’ or changing the default does not add value. Restricting the change to NAMELIST adds needless complexity. |
|
I have modified #67 to make it clear that current list-directed output should not be affected. And objection to greater complexity does not feel like a valid argument for me. It's a complex situation caused by the existing rules (i.e. namelist output formatted according to list-directed output rules) and is producing incompatible output. Why not introduce the necessary level of complexity which resolves the problem? (And given that GFortran is already doing the sustainable thing, I doubt it ought to be considered a complex rule.) And I'm only raising this because I have supported and still support models which use namelists which get passed through workflow managers of greater complexity as times goes on. These problems with string formatting happen too often and take too much time to debug. And telling users to add a DELIM does not inspire faith in the language. I apologize if this is getting off track from the larger conversation of retaining backwards compatibility. And I also fully understand that this isn't a serious problem for most Fortran users, which is already a very rarefied group. But I don't see the point in retaining backwards compatibility to something which is broken. |
Backward compatibility, or not to break existing code, is often put forth as the argument against many a proposal, this issue #40 is a classic instance of this. This issue #72 is also seeing a similar debate.
However there appear to be 2 major issues with this argument:
it is very difficult, almost impossible, to find an objective analysis of the risks due to a change. If a breaking change is only a theoretical possibility but if most or all the publicly known codebases are not noticed to be at risk due to the change, how valid is the argument then to not consider an idea?
on the other hand, there exist quite a few instances in the standard where compatibility with an earlier revision has been dropped for some aspect or other, often presented as different interpretations but they also include features which are DELETED such as from FORTRAN 77 and earlier editions.
Consider the current Fortran 2018 standard: with respect to Fortran 2008 itself, one can argue changes have been incorporated that break existing code, at least under the theoretical possibility of conforming processors offering support for the prior interpretation. With object-oriented facilities in Fortran, my codes have had to deal with "breaking changes" in going from processors supporting Fortran 2003 thru' 2018.
So what it appears to me is an inconsistency in how the "backward compatibility" argument is applied and perhaps even an inaccuracy in the argument "oh, that will break existing code and that is a no-no" that is put forth.
It'll be valuable for Fortran if a technical approach to address the bugaboo of backward compatibility can be adopted.
One aspect of such an approach might involve the establishment of a "registry" of Fortran codebases: such a registry only need to have links to existing projects online such as GitHub, SourceForge, etc. or to institutional sites e.g., DOE, NASA, NOAA, academia, etc., or simply be entries which provide a brief description of what code does and the coding styles adopted per true intent e.g., the use of IMPLICIT typing (as opposed IMPLICIT NONE), or IMPLICIT SAVE, data types, and so forth. This can a "green" registry of course, meaning it should grow as new applications are developed using Fortran.
Then when a proposal is presented, one can crosscheck it against such a registry for impact analysis (and where possible like with GitHub or online repositories with a code review) to yield a somewhat quantitative assessment of the risk due to the change; this is as opposed to someone's 'gut feel' at present which might be overestimating the adverse impact of a proposal.
The text was updated successfully, but these errors were encountered: