From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,b084786fb95b5938 X-Google-Attributes: gid103376,public From: stt@houdini.camb.inmet.com (Tucker Taft) Subject: Re: Adding Things to Package System Date: 1999/02/27 Message-ID: #1/1 X-Deja-AN: 449293300 Sender: news@inmet.camb.inmet.com (USENET news) X-Nntp-Posting-Host: houdini.burl.averstar.com References: <1999Feb26.202551.9334@nosc.mil> Organization: Intermetrics, Inc. Newsgroups: comp.lang.ada Date: 1999-02-27T00:00:00+00:00 List-Id: Charles H. Sampson (claveman@cod.nosc.mil) wrote: : ... : I'm not really happy with Tucker's response, but I'm not too sur- : prised either. I am a little surprised about a couple of terms that I'm : not familiar with: "portably 'legal' code" and "'universally' legal". : Other than that, I suppose that the demon Practicality is going to com- : mand that additions to System be allowed in the near term. Perhaps in : Ada 200X, ... I didn't mean anything mysterious about "universally" or "portably" legal. Fundamentally, your program as written isn't portable. It is legal on some compilers, and illegal on others. Ada 83 allowed additions to System, and to Standard for that matter. To write a portable Ada 83 program, you had to take this into account. Unfortunately, we could not easily eliminate this source of non-portabilities by Ada 95 fiat, given the > 100M LOC of Ada 83 code. : Still, even though it's not surprising, saying that 1.1.3(2) is : not a hard rule is disturbing. It is a hard rule. But it is relative to a particular environment. An Ada program is not legal independent of the environment in which it is compiled. It must accommodate the particular package Standard and the particular library units in the environment. In some environments, package Standard and/or package System might have additional declarations. : ... In spite of that, the rule that a : conforming implementation must handle all legal Ada programs is "bent" : to allow these additions. Again, there is no bending. It is a simple case of allowed implementation- dependence in the specification for a language-defined package. : ... (I haven't been able to find the definition : of a legal Ada program, using the index of the LRM as my main tool. My : guess would be that it is a program written in the language as described : in the LRM. In that case, my program was legal.) A program is legal if it satisfies the syntax, name resolution rules, and legality rules in the LRM. Your program violated one of the name resolution rules because of a permitted variation in a language-defined package. : I almost always write highly portable code. I do it by being very : careful of how I use those features that have implementation dependen- : cies and by not using implementation additions unless absolutely neces- : sary. However, in the present example, I was tripped up by an addition : that I wasn't using. I guess I felt a little let down by the LRM. Because implementation are permitted to add declarations to packge System, "use System;" is a "non-portable feature". You may need to add that to your list of things to avoid. : Yes, there are a number of ways of getting around the problem of : additions to System, but I don't see why I should have to. You only "have to" do it if you want to create maximally portable programs. : ... I would like : to see some authority (is an ARG 95 in business?) come out very strongly : in favor of the second sentence of 13.7(36): Any additions to System : should be done in a child package rather than in System itself. The key word is "should" here. It is implementation advice, not a hard requirement, and because of the large amount of existing Ada 83 code, some vendors have felt obliged to maximize upward compatibility. Perhaps the real mistake was not to be more explicit in some RM "NOTE" that any "use" clause for package System is inherently non-portable, because additions to package System are permitted. For what it is worth, other non-portabilities to be aware of are ueses of names like "Byte_Integer", "Short_Integer", "Long_Long_Integer" in your own packages which you then "use," because of potential conflicts with additions to package Standard. As you point out, portability is not an absolute in Ada 95, and requires some user effort to achieve. Avoiding "use System;" is part of the effort required to maximize portability. : Charlie -- -Tucker Taft stt@averstar.com http://www.averstar.com/~stt/ Technical Director, Distributed IT Solutions (www.averstar.com/tools) AverStar (formerly Intermetrics, Inc.) Burlington, MA USA