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,6c97cf9ad4aaff3e X-Google-Attributes: gid103376,public From: Gene Ouye Subject: Re: Which "/" is referenced in a numeric literal expression? Date: 1996/02/26 Message-ID: X-Deja-AN: 141182294 references: <4ft4u5$eu2@news.sanders.lockheed.com> <4g2c51$ep@news.sanders.lockheed.com> <4gcifh$itt@news.sanders.lockheed.com> <4gkil1$837@news.sanders.lockheed.com> content-type: TEXT/PLAIN; charset=US-ASCII organization: Rational Software Corporation mime-version: 1.0 newsgroups: comp.lang.ada Date: 1996-02-26T00:00:00+00:00 List-Id: jgamache@mailgw.sanders.lockheed.com (Joe Gamache) wrote: [Dewar's comment in this thread that seems never to die deleted... (and I, hook in mouth, continue it further-- feel free to ^K this thread...)] > The position is, in fact, easily defendable. Perhaps you should more > carefully research the prior posts in this thread. The originator > _actually_ had a question about the use of _constants_ in some GNAT > supplied software. In the simplication "process", this facit concerning > constants was removed. Because I (unfortunately) was the original poster, I feel some (small) obligation to reply. My initial question was for an RM reference that would explicitly state the behavior for resolving an overloaded operator when one of the candidate resolutions was with operands of a universal type. The fact that they were "constants" (actually, named numbers) was irrelevant, the fact remains that their type was universal_integer. I did NOT want to see irrelevant discussion about whether or not they should (or should not) have been constants, and I did NOT want people running off trying various irrelevant combinations of things with their compilers to figure out what was wrong. What I wanted was a simple explanation (with RM references) of how universal types fit into overload resolution, although when I first posted, I wasn't sure that that was what I needed. What I didn't understand was the relationship between the root numeric types and the universal types, and the fact that there are no predefined operators for the universal types. (Thanks Tucker for the explanation) > Thus, the "simplified" model was generalizable > (if that is a word...) to an ADT package. Your _opinion_ may be that > ADT packages have no rules, or are "completely independent of style." I'm glad that you were able to see an ADT in my simple example. However, the point of the simplified example was to remove as many extraneous language features as possible so that the RM references would be kept to a minimum. I didn't want to see the number of cited RM references grow exponentially with the increase in the number of language features used in the example. I would hope that anyone else who posts questions about the language would try to do the same. I certainly encourage my customers to try and distill problems down to their minimum, so that any efforts expended to resolve them are spent focusing on the correct issues. > My _opinion_ is that there are certain rules which should _always_ be > complied with on such packages. Chief among these is compliance with > the rules first outlined by Parnas (in "On the Criteria to be used in > Decomposing a System in Modules") back in 1972: in this he says, > a "data structure, its internal linkings, accessing procedures and > modifying procedures are part of a single module". My example didn't violate this. It's reposted here: package A is type A_Type is range -128 .. 127; end A; with A; package B is Some_Num : A.A_Type := 32 / 8; end B; >From the code posted here, you can't determine the structure of A.A_Type--you can assume that whatever it is, it's capable of holding integer numbers in the range -128 through 127, that's it. You can't assume that it's implemented in a byte, or a word. For all you know its stored as packed-decimal, or as a list of individual characters that are interpreted when needed. You know nothing of the internal linkings, that's all hidden. The only accessors and modifiers of A.A_Type are the operators and operations defined in the RM for integer types. I can't change them, and I certainly can't get to their implementation. In fact, all the "accessing" and "modifying" procedures come into existence in package A, and can't be mucked with outside of A. The only way I can change variables of type A.A_Type is through those operations. > This rule was > delinated further by Liskov and Zilles in 1975: "... with the constraint > that the behavior of the objects can be observed only by applications > of the operations". So how can anything be done with or to objects of A.A_Type without going through the operations such as A."/", A."+", A."-", etc? > I merely pointed out the inconsistency between > the original post and these tenets. There is no inconsistency. I certainly made no attempt to make sure that my example was a good example of an ADT, although purely by coincidence, it turns out to be a perfectly acceptable one. > Ironically, had the intent of the > _real_ problem, involving the use of constants, been maintained, my > objections disappear. The "_real_" problem is that values of the type A.A_Type look exactly like the values of any other integer type, and that A.A_Type literals look just like any other universal integers (because, in fact, there are no A.A_Type literals, every numeric literal is universal_integer, which can be implicitly converted into any integer type). with System.Storage_Elements; package B is Some_Num : System.Storage_Elements.Storage_Count := System.Memory_Size / Standard'Address_Size; end B; There, now it looks more like the original code. Does that make it any better? Is it easier to understand? Will this make it easier for people to answer my question about operations on universal types? Can you even tell now that this is an issue with operations on universal types? My question had nothing to do with GNAT design, it had nothing to do with proper or improper use of System.Storage_Elements.Storage_Count, it had nothing to do with whether or not I was making proper use of an ADT, or whether I had even designed an ADT well. It had nothing to do with the attribute 'Address_Size, it had nothing to do with whether or not Standard 'Address_Size was the same thing as System.Word_Size, or whether it was the same thing as System.Address'Size. But how many people looking at the above code would have immediately realized that and just focused on the real issue? > As always in these matters, you and anyone else > are free to feel otherwise.... I did. Gene Ouye