Re: Which "/" is referenced in a numeric literal expression?

[Gene Ouye <geneo@rational.com>]

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 <geneo@rational.com>