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,56250291936154a0 X-Google-Attributes: gid103376,public From: Richard D Riehle Subject: Re: Where is the elusive jump command? Date: 2000/03/30 Message-ID: <8c088m$puh$1@slb6.atl.mindspring.net> X-Deja-AN: 604462127 References: <38D771CA.D41AF9B5@port.ac.uk> <8bq7ku$mc8$1@nnrp1.deja.com> <38E0E723.C39C392@quadruscorp.com> <8brfm4$4uc$1@nnrp1.deja.com> <8brn4k$p6i$1@slb0.atl.mindspring.net> <8brrpj$i04$1@nnrp1.deja.com> Organization: MindSpring Enterprises X-Server-Date: 30 Mar 2000 19:00:38 GMT Newsgroups: comp.lang.ada Date: 2000-03-30T19:00:38+00:00 List-Id: In article <8brrpj$i04$1@nnrp1.deja.com>, Robert Dewar wrote: >In article <8brn4k$p6i$1@slb0.atl.mindspring.net>, > Richard D Riehle wrote: >> >> To write such a compiler, it is necessary to include certain >> reserved words and syntactic constructs that "tip off" the >> compiler to possible problems. The word _aliased_ seems to me >> to be one of those "tip-off the compiler" words. This can >> later be augmented with a more technical explanation, but it >> works well for most early students when explained within the >> framework of the above stated goals. > >I find this a very odd view of the ALIASED keyword. The reason >for this has nothing to do with the compiler. As in the case >of most C compilers, the compiler could look at your code to >see whether or not you take the address of something. That's >not at all the intention. This could have been accomplished without the word _aliased_ keyword. Could it have been as easily checked by the compiler? It seems to me that _aliased_ helps prevent the very kind of errors one encounters in C. If the reserved word is not intended to provide special information to the compiler, why not just do this the same way we do it in C? The fact is that I cannot use 'Access on a value that is not aliased. The compiler prevents it. Hence, I see this is as a signal to the compiler that I am trying to do something illegal. It is also a tip-off to the compiler that accessibility rules need to be enforced. Whatever the original intent of _aliased_ , it has the effect of letting the programmer know about the legality or illegality of a syntactic construct, ensuring that certain practices are avoided, and making it clear what one's intentions are in the source code. >The point is that aliasing is generally speaking very bad >practice. The facility for pointing to variables was introduced >in Ada 95 with reluctance when certain convincing examples >were given, including in particular the construction of >static structures involving pointers. I am one of those people who understands the reluctance to introduce this construct into Ada. It turns out to be a valuable feature of the language and the accessibility rules do make it a little bit safer than the corresponding code in C. Of course, Unchecked_Access does allow unruly behavior from some programmers. >It should be VERY sparingly used, really it should be regarded >like Unchecked_Conversion, a noisy declaration that you intend >to do something rather undesirable, namely in this case the >creation of possibly confusing aliases for the variable. Lots of things should be sparingly used. One might say the same about tagged types and inheritance. Certainly most agree that _goto_ should be sparingly used. Indeed, you wrote a thoughtful contribution last year asserting that assignment should be sparingly used. Perhaps requiring the reserved word _aliased_ encourages the sparing use of it in source code. There are situations, particulary interfacing with some of the operating system facilities, where a general access type, and the word _aliased_ makes good sense. Also, many of the programmers I deal with in my daily work are former C/C++ programmers who are accustomed to working without a safety-net. For them, the accessibility rules associated with _aliased_ values, make sense, even though they are sometimes a bit annoying. >Note by the way that 'Address can be applied freely to variables >in any case without the ALIASED keyword, so Ada 95 compilers in >any case have to have the circuitry for automatic detection of >which variables have their addresses taken and which do not >(GNAT most certainly has this circuit). Thus ALIASED is not of >the slightest utility to the compiler (in GNAT it is essentially >ignored except for providing the essential semantic checking >associated with this facility). OK. Semantic checking seems somewhat important. The compiler does check this. Why bother with it? It seems to me that this is because there are some associated rules, and these are checked at compile time. To my mind, this illustrates one of the most important aspects of Ada: maximizing detection of programmer stupidity at compile time. Perhaps _aliased_ is of no importance to the compiler from the point-of-view of creating an operational compiler. That would be true, I suspect, of many other Ada features. Donald Knuth is fond of reminding us that we are not writing programs for compilers but for ourselves and other people. We make mistakes. Well, I do anyway, lots of them, it would seem. The Ada language helps us minimize those mistakes by enabling a compiler technology that notices those mistakes. The keyword, _aliased_ , may be of no intrinsic value to the compiler, but it does "tip off" the compiler to the reality that we may have made some silly error in our coding. When the compiler informs of us of this fact, we have the option of correcting our code. Is this a superfluous notification? I don't think so. As to 'Address, this is really fraught with potential dangers. Now there is a language construct that needs to be used sparingly. Richard Riehle