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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,c1131ea1fcd630a X-Google-Attributes: gid103376,public From: Ken Garlington Subject: Re: To Initialise or not Date: 1996/05/13 Message-ID: <31976E53.5152@lmtas.lmco.com> X-Deja-AN: 154659974 references: <318508FE.204B@sanders.lockheed.com> <3190A8D3.3D53@lmtas.lmco.com> <3196FBD9.6AA1@lmtas.lmco.com> content-type: text/plain; charset=us-ascii organization: Lockheed Martin Tactical Aircraft Systems mime-version: 1.0 newsgroups: comp.lang.ada x-mailer: Mozilla 2.01 (Macintosh; I; 68K) Date: 1996-05-13T00:00:00+00:00 List-Id: Robert A Duff wrote: > > >1. Use of "others" in an aggregate expression, case statement, etc. > > I don't use "others" very often. "Others" means, to me, that I mean > to include all "other" cases, including the ones that haven't been > invented yet. Sometimes that makes sense. So, if you needed to set a long string to all blanks, you wouldn't use (others => ' ') unless you expected that the size of the string would change? > I'm not complaining about implicitness in general. When I write > "others", or when I write a default value for a record component, I'm > the one writing the program and I know what I'm doing. In the > implicit null case, Jean Ichbiah decided in 1980 that my pointers > should be initialized to null, and of course he had no idea what my > program needs today. Well, he presumed that you wanted a deference of a pointer to always be detected, which certainly seems like a good guess, given the history of pointers used in other languages. > My point is that the programmer, not the > language designer, should be in charge of deciding whether a default > value is a good idea, and if so, what that default value should be. > The language should be in charge of detecting uninit vars. Or, alternately, providing the building blocks for you to effectively extend the language (which I believe Normalize_Scalars and 'Valid lets you do, when used with an ADT or GADT). Which things should be "hard-wired" in the language and which should not is always going to be a philosophy issue. If your real complaint is that you would rather have a pragma Normalize_Accesses instead of the default initialization to null, that's OK I guess (although I don't know how that would work, since you can't really talk about the range of an access value in Ada 95). I still don't see how your coding convention helps this issue in any meaningful way, however. > Note that I'm not saying you should always initialize to 'null'. I'm > perfectly happy to see "X: Some_Pointer := new Something'(...);" or > "X: Some_Pointer := Some_Other_Pointer;". Right - there's nothing wrong with those other initializations. The intent of the initialization is (or should be) clear in each case. It's just the literal "null" that I find wanting. > > >However, I think it's "philosophy" that's backed up by experience in > >maintaining code. Have you done experiments that showed the value of adding > >extra code in this case? > > No, I have no experimental evidence. > > >> Let me be quite clear about what I would *like* in a language: Any type > >> that's built in to the language, and is treated as a non-composite > >> entity, should have run-time detection of uninit vars. > > > >OK. Why do you feel that you can't achieve this in Ada? With Ada 95, you > >have the ability to detect uninitialized scalars at any point in the program, > >so long as the compiler can generate a "marker" value for the object (and > >it supports the Safety and Security annex, of course). > > Because (1) it only works for types don't need extra bits, and (2) not > every reference is detected. Well, assuming that my condition holds (a marker value is possible), and you use an abstraction for the reads to the type, it should detect every reference via the abstraction. Actually, even if a direct marker isn't possible, you can create an auxiliary marker (a boolean bundled with the "real" type) in the abstraction. > >However, to do this consistently in Ada, you need to make a data abstraction > >for each type for which you want such protection. Just providing a redundant > >initialization fails to meet your goal. > > Agreed. But I'm not going to invent a new abstraction for indexing > Strings. I'm going to use type Integer. That's your call, of course. However, I don't see the alternative to get what you want reliably (Normalize_Scalars will still detect an error, occasionally, of course). I'm still mystified how initialization to null helps you here... > I never said "integers are exactly like access types in every > respect". So your argument is bogus. I just said they should be > alike with respect to detection of uninitialized vars. My argument was only with respect to initialization -- which is exactly where you said your argument resided (your previous post mentioned explicit initialization rules, not detection of uninit vars). All I said was, "why not treat integers and aggregates alike with respect to initialization, just as you want to treat integers and accesses alike with respect to initialization?" Seems perfectly "consistent" for me. > (I hope we > both agree that it's good that arithmetic is available for integers, > but not for access types.) Actually, when writing OS code in Ada 83, I have had need to do unchecked conversions to convert access types to integers so that I could do simple arithmetic on them. I certainly agree that you shouldn't provide such operations by default, however. Aren't you making my point? Access types are fundamentally different from integers, so why should the initialization rules be alike? Of course, in Ada 95, I _can_ do arithmetic on an access type _portably_. Ain't Ada grand? > > - Bob -- LMTAS - "Our Brand Means Quality"