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

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

[Robert Dewar]

Joe said

"Since the example is a violation of the OO principles you propose
to teach, I guess we also differ on this point.  Simplification of
an
example to a point where it shows _anyone_ how to do something
wrong is not IMO *good*."

What a peculiar comment! This was a reduced version of a little bit of
Ada to ask a language question, no style issues were in sight here. Very
often the examples we use to illustrate language questions are in "ppor
style" preciesely because you want to distill out irrelevant stuff.

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

[Joe Gamache]

In article <dewar.824576957@schonberg>, dewar@cs.nyu.edu says...
>

>What a peculiar comment! This was a reduced version of a little bit of
>Ada to ask a language question, no style issues were in sight here. Ve
>ry
>often the examples we use to illustrate language questions are in "ppo
>r
>style" preciesely because you want to distill out irrelevant stuff.
>

The reduced version of my point is simple: since the example made use
of a "style" that should be avoided, the answer to the language question
is somewhat moot.  Not that the question should not be answered.  But 
rather, "here's the answer, BTW it doesn't matter since you shouldn't
ever be doing this anyway...."

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

[Robert Dewar]

Joe said

"The reduced version of my point is simple: since the example made use
of a "style" that should be avoided, the answer to the language question
is somewhat moot.  Not that the question should not be answered.  But
rather, "here's the answer, BTW it doesn't matter since you shouldn't
ever be doing this anyway....""

Sorry, that is an untenable position. The language point in question was
completely independent of style. The point could have come up in programs
consistent with any style you want. The idea that language examples used
to discuss language issues should be in "good style" whatever that means
(style, unlike language issues is notoriously subjective) is completely
unhelpful.

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

[Joe Gamache]

In article <dewar.824904896@schonberg>, dewar@cs.nyu.edu says...
>
>Joe said
>
>"The reduced version of my point is simple: since the example made use
>of a "style" that should be avoided, the answer to the language questi
>on
>is somewhat moot.  Not that the question should not be answered.  But
>rather, "here's the answer, BTW it doesn't matter since you shouldn't
>ever be doing this anyway....""
>
>Sorry, that is an untenable position. The language point in question w
>as
>completely independent of style. The point could have come up in progr
>ams
>consistent with any style you want. The idea that language examples us
>ed
>to discuss language issues should be in "good style" whatever that mea
>ns
>(style, unlike language issues is notoriously subjective) is completel
>y
>unhelpful.
>
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.  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."
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".  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".  I merely pointed out the inconsistency between 
the original post and these tenets.  Ironically, had the intent of the
_real_ problem, involving the use of constants, been maintained, my 
objections disappear.  As always in these matters, you and anyone else
are free to feel otherwise....

----------------------------------------------------------------
Joe Gamache
Sanders, a Lockheed Martin Co.

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

[Gene Ouye]

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>