about inheritance of subtypes and entities (such as constants) related to a type in the same package

about inheritance of subtypes and entities (such as constants) related to a type in the same package

[Mehdi Saada]

Hello. In my reading of Barnes' book I learn many little details that aren't apparent in the rm... no surprise.
Being used to much readability, I'm surprised, however, by the situation with inheritance:

with Ada.Text_IO;
package AA is
   type A is private;
   subtype B is A;
   function IS_IN_B(obj: A) return boolean;
   procedure TEst_B (Obj_B: B) is Null;
private
   type A is new Integer;
end AA;

So if I derive a new type from A in another package, it would inherit IS_IN, but not the declaration of B ? This declaration would become anonymous and I would have to means to get, say, B'range or whatever attributes it has ("private" was for convenience), but to look in package AA from where A comes ?
Also, no being able to do things like "pragma Assert (Obj in <new_anonymous_subtype>);" seems pretty lame. Or did I misunderstood something ?

It could have been decided that subtypes of a type declared in the same package, are inherited as would be subprograms. Same goes for constants. Which subtype B is mentioned (from A or C) would be resolved at least at compile time. Having the same name isn't that good, but that's secondary.

Re: about inheritance of subtypes and entities (such as constants) related to a type in the same package

[Mehdi Saada]

Something else entirely but it's said packages can't have dependent tasks... What ?
The body below is legal, whatever the package:
package body III is
   task T1;
   task body T1 is
   begin
      delay 5.2;
   end T1;
begin
   delay 0.5;
end III;
So what does it mean ?

Re: about inheritance of subtypes and entities (such as constants) related to a type in the same package

[Randy Brukardt]

Packages are not themselves a runtime "master" (they're just an compile-time 
organization feature), so a task declared in a package belongs to whatever 
the package is declared in. In the case of a library package, that's 
Standard and the environment task.

Note that this has nothing to do with what is legal,  just who the owner of 
the task is.

                                          Randy.

"Mehdi Saada" <00120260a@gmail.com> wrote in message 
news:f414db5e-0da3-43ad-81eb-7f882a9bea58@googlegroups.com...
> Something else entirely but it's said packages can't have dependent 
> tasks... What ?
> The body below is legal, whatever the package:
> package body III is
>   task T1;
>   task body T1 is
>   begin
>      delay 5.2;
>   end T1;
> begin
>   delay 0.5;
> end III;
> So what does it mean ? 

Re: about inheritance of subtypes and entities (such as constants) related to a type in the same package

[Randy Brukardt]

Inheritance in Ada was designed by Ichbiah in the late 1970s, long before 
anyone really understood OOP or similar systems. It's (IMHO) not very well 
designed, but we're stuck with it. The *only* things inherited in Ada is 
primitive subprograms and operators. Some predefined stuff like memberships 
gets regenerated for each type. Otherwise, there's no inheritance. Objects 
and subtypes in particular are not part of it. (Depending on the use, you 
may or may not want them, but it isn't possible at all.)

In the case of constants, there's an easy solution: use a function instead. 
Otherwise, though, you have to be careful.

Changing inheritance would be wildly incompatible, so I don't think there is 
any chance of that.

                                                      Randy.


"Mehdi Saada" <00120260a@gmail.com> wrote in message 
news:ecd599f8-bb04-4304-9242-1c88edee4a4e@googlegroups.com...
Hello. In my reading of Barnes' book I learn many little details that aren't 
apparent in the rm... no surprise.
Being used to much readability, I'm surprised, however, by the situation 
with inheritance:

with Ada.Text_IO;
package AA is
   type A is private;
   subtype B is A;
   function IS_IN_B(obj: A) return boolean;
   procedure TEst_B (Obj_B: B) is Null;
private
   type A is new Integer;
end AA;

So if I derive a new type from A in another package, it would inherit IS_IN, 
but not the declaration of B ? This declaration would become anonymous and I 
would have to means to get, say, B'range or whatever attributes it has 
("private" was for convenience), but to look in package AA from where A 
comes ?
Also, no being able to do things like "pragma Assert (Obj in 
<new_anonymous_subtype>);" seems pretty lame. Or did I misunderstood 
something ?

It could have been decided that subtypes of a type declared in the same 
package, are inherited as would be subprograms. Same goes for constants. 
Which subtype B is mentioned (from A or C) would be resolved at least at 
compile time. Having the same name isn't that good, but that's secondary. 

Re: about inheritance of subtypes and entities (such as constants) related to a type in the same package

[Dmitry A. Kazakov]

On 2018-05-30 12:12 AM, Randy Brukardt wrote:

> Changing inheritance would be wildly incompatible, so I don't think there is
> any chance of that.

We can just add another method of inheritance as it has been 
successfully done with tagged types. We need interface inheritance from 
a concrete type with user-defined conversion operations to support 
substitution and class-wide values in the form (tag, value).

BTW, the old inheritance has a very powerful and very useful mechanism 
of cloning types:

    type S is new T;

There is much reason for both methods to coexist. Presently in order to 
be able to clone tagged type I must place its root type in a generic, 
which is huge overkill.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: about inheritance of subtypes and entities (such as constants) related to a type in the same package

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:pelmg4$v5t$1@gioia.aioe.org...
> On 2018-05-30 12:12 AM, Randy Brukardt wrote:
>
>> Changing inheritance would be wildly incompatible, so I don't think there 
>> is
>> any chance of that.
>
> We can just add another method of inheritance as it has been successfully 
> done with tagged types.

The part of inheritance that I was talking about (because it was relevant to 
the OPs question) is exactly the same for tagged types and untagged types. 
The differences are in class-wide operations and the possibility of dynamic 
dispatching.

                                        Randy.

Re: about inheritance of subtypes and entities (such as constants) related to a type in the same package

[Dmitry A. Kazakov]

On 2018-05-30 21:25, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:pelmg4$v5t$1@gioia.aioe.org...
>> On 2018-05-30 12:12 AM, Randy Brukardt wrote:
>>
>>> Changing inheritance would be wildly incompatible, so I don't think there
>>> is any chance of that.
>>
>> We can just add another method of inheritance as it has been successfully
>> done with tagged types.
> 
> The part of inheritance that I was talking about (because it was relevant to
> the OPs question) is exactly the same for tagged types and untagged types.
> The differences are in class-wide operations and the possibility of dynamic
> dispatching.

I don't see any commonality. One method produces an independent type 
another does a related types. If you mean specifically inheritance of 
operations and the representation, that plays no role because of the 
difference in the types.

Nothing can be incompatible with independent types if you could also 
derive from one of them a related type. They simply never meet being 
unrelated to each other.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: about inheritance of subtypes and entities (such as constants) related to a type in the same package

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:pemv0i$1clu$1@gioia.aioe.org...
...
> I don't see any commonality. One method produces an independent type 
> another does a related types. If you mean specifically inheritance of 
> operations and the representation, that plays no role because of the 
> difference in the types.

The OP was asking specifically why subtypes and objects aren't inherited, so 
it surely plays a role in answering him. The difference in the definition of 
the types is irrelevant in how inheritance of other things is defined. One 
can argue that was wrong, but it is a fact.

                                                   Randy.

Re: about inheritance of subtypes and entities (such as constants) related to a type in the same package

[Dmitry A. Kazakov]

On 2018-05-30 09:59 PM, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:pemv0i$1clu$1@gioia.aioe.org...
> ...
>> I don't see any commonality. One method produces an independent type
>> another does a related types. If you mean specifically inheritance of
>> operations and the representation, that plays no role because of the
>> difference in the types.
> 
> The OP was asking specifically why subtypes and objects aren't inherited, so
> it surely plays a role in answering him.

Why should subtypes be inherited? The question itself does not make 
sense. A type cannot be inherited it is not a property of a type. [*]

I still see no relation. Ada subtype is a mechanism to produce an 
equivalent type. It is fully orthogonal to other forms of inheritance.

> The difference in the definition of
> the types is irrelevant in how inheritance of other things is defined. One
> can argue that was wrong, but it is a fact.

Relevant is that no definition of inheritance in the mechanism A can 
break the mechanism B as they produce different types.

-------------------
* It could be of the there were type-valued types (types type) + 
inheritance from these 2nd-order types. Then a value (1st-order type) of 
a 2nd-order type could be inherited, but that would have nothing to do 
with inheritance from 1st-order types.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: about inheritance of subtypes and entities (such as constants) related to a type in the same package

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:peockk$1g59$1@gioia.aioe.org...
> On 2018-05-30 09:59 PM, Randy Brukardt wrote:
...
>> The OP was asking specifically why subtypes and objects aren't inherited, 
>> so
>> it surely plays a role in answering him.
>
> Why should subtypes be inherited? The question itself does not make sense. 
> A type cannot be inherited it is not a property of a type. [*]

I'm not sure, either. But that was the question. Perhaps we all should have 
concentrated on answering that??

                                     Randy.

Re: about inheritance of subtypes and entities (such as constants) related to a type in the same package

[Mehdi Saada]

The idea was to define for a given (private) type, a series of subtypes with different type invariant, or with or without unknown discriminants (the box), to provide specific variant of the same ADT.
I know now that is meant to be done through tagged types, and that subtypes are no good for that. But I would have liked a mechanism to generate, why deriving a new type from a parent, these tailored subtypes, with the same same, just like they would have been rewritten.
But it doesn't take much to see it wasn't a good idea, and that a lot problem would occur... like: what happens when the derived type has constraints or invariants incompatible with subtypes associated with the parent ?

I should say "Copying" rather than inheriting. "Copying" constants would fail for the same reason. I/one is better of with converting the constants defined once, for the whole type hierarchy. Though the problem is only with untagged types, tagged private types have class-wide constants.

Re: about inheritance of subtypes and entities (such as constants) related to a type in the same package

[Shark8]

On Thursday, May 31, 2018 at 5:39:52 PM UTC-6, Mehdi Saada wrote:
> The idea was to define for a given (private) type, a series of subtypes with different type invariant, or with or without unknown discriminants (the box), to provide specific variant of the same ADT.

Can you give an example?
Something like Stack, Empty-Stack, Integer-Stack? I'm not entirely sure I get what you're saying, or what your intended goal is.

Re: about inheritance of subtypes and entities (such as constants) related to a type in the same package

[Dmitry A. Kazakov]

On 2018-06-01 01:39 AM, Mehdi Saada wrote:
> The idea was to define for a given (private) type, a series of subtypes with different type invariant, or with or without unknown discriminants (the box), to provide specific variant of the same ADT.

OK, this is a set of related types (though Ada pundits would claim that 
subtype is not a type).

> I know now that is meant to be done through tagged types, and that subtypes are no good for that.

No, you cannot do that with tagged types. These are two different 
type-algebraic operations:

1. subtype creates a new subtype by constraining the base

2. tagged extension creates a new "subtype" by using a set product over 
the original values set

None substitutes another, but you can mix them. They are fully orthogonal.

> But I would have liked a mechanism to generate, why deriving a new type from a parent, these tailored subtypes, with the same same, just like they would have been rewritten.

Deriving creates a new type in a class of types. When you create an Ada 
subtype it is a new member of the class rooted in the base type. When 
you derive from a tagged type T you add a new member to the class rooted 
in T.

What you want is to copy a whole class. It is a second order type 
operation. Ada has two means for that:

1. Type cloning:

    type X is new Y;

This does not work for tagged types and it does not clone subtypes.

2. Generic instantiation.

This works for anything, but imposes severe software design problems.

> But it doesn't take much to see it wasn't a good idea, and that a lot problem would occur... like: what happens when the derived type has constraints or invariants incompatible with subtypes associated with the parent ?

That cannot happen because constraints are inherited. If you need 
another constraint you derive another type.

> I should say "Copying" rather than inheriting. "Copying" constants would fail for the same reason. I/one is better of with converting the constants defined once, for the whole type hierarchy. Though the problem is only with untagged types, tagged private types have class-wide constants.

Both mechanisms copy literals if that is what you meant.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: about inheritance of subtypes and entities (such as constants) related to a type in the same package

[Dan'l Miller]

On Tuesday, May 29, 2018 at 5:12:23 PM UTC-5, Randy Brukardt wrote:
> Inheritance in Ada was designed by Ichbiah in the late 1970s,

Ummmmmmm, am I the only one cringing that the words {inherit, inheritance} are being utilized at all regarding Ada83?  Everyone please check the index of the Ada83 _LRM_.  The words {inherit, inheritance} never appear there at all.  The derived-type and subtype concepts are defined rather differently than any OO-esque definition of inherited.

Yes, I realize that this thread is speaking colloquially in retrospect about Ada83 features as primordial pre-OO.  But the OP's entire topic is predicated on subtyping and type-derivation of non-tagged types that then abuses the OO/Ada95 term "inheritance" as a proleptic anachronism, back misapplying inheritance to the entirely-different Ada83 language that clearly lacks inheritance, in both name and spirit (or primordial soup thereof).  Rather, Ada83 has type derivation and subtyping, which despite the similarity of the name subtyping with OO's subclassing (made worse by C++'s & then later Java's abuse of the term class to mean a single type instead of a tree of types), subtyping in Ada83 has nothing to do with subclassing in Ada95 or any other OO language.

This whole thread seems to have gotten off on the wrong foot of slamming  proleptic anachronisms from Ada9X program ideas into Ada83 and never really sorted out that fundamental mistake.

> long before 
> anyone really understood OOP or similar systems.

Well, there was Simula in the 1960s.  No less than Tony Hoare himself devised the entire concept of a class of records in an inheritance hierarchy in 1966 for Simula.  Hoare & Wirth were involved with defining Yellow, a competitor of Green/Ada.  So there was some amount of big-brandname awareness of OO even within the Ada color-languages competition during the 1970s.

https://en.wikipedia.org/wiki/Simula

And there was Smalltalk80, a contemporary of Ada, defined nearly the same years as the selection of Ada/Green.

Re: about inheritance of subtypes and entities (such as constants) related to a type in the same package

[Dmitry A. Kazakov]

On 2018-05-30 10:53 PM, Dan'l Miller wrote:

> Yes, I realize that this thread is speaking colloquially in retrospect about Ada83 features as primordial pre-OO.  But the OP's entire topic is predicated on subtyping and type-derivation of non-tagged types that then abuses the OO/Ada95 term "inheritance" as a proleptic anachronism, back misapplying inheritance to the entirely-different Ada83 language that clearly lacks inheritance, in both name and spirit (or primordial soup thereof).

No, it is still inheritance. Ada 83 subtype inherits operations and 
representation of the base type. Similarly Ada 83 cloned type (type X is 
new Y) inherits (clones) both.

> Rather, Ada83 has type derivation and subtyping, which despite the similarity of the name subtyping with OO's subclassing (made worse by C++'s & then later Java's abuse of the term class to mean a single type instead of a tree of types), subtyping in Ada83 has nothing to do with subclassing in Ada95 or any other OO language.

Yes, but these are names for the same concept of a types algebra 
operation when a new type is produced from an old type by *inheriting* 
some of the operations and representations of the old.

Different are the ways of inheritance and methods of achieving 
substitutability. Ada 95 introduced a new (for Ada) method in addition 
to the methods Ada 83 already had.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: about inheritance of subtypes and entities (such as constants) related to a type in the same package

[Dan'l Miller]

On Thursday, May 31, 2018 at 3:54:22 AM UTC-5, Dmitry A. Kazakov wrote:
> On 2018-05-30 10:53 PM, Dan'l Miller wrote:
> 
> > Yes, I realize that this thread is speaking colloquially in retrospect about Ada83 features as primordial pre-OO.  But the OP's entire topic is predicated on subtyping and type-derivation of non-tagged types that then abuses the OO/Ada95 term "inheritance" as a proleptic anachronism, back misapplying inheritance to the entirely-different Ada83 language that clearly lacks inheritance, in both name and spirit (or primordial soup thereof).
> 
> No, it is still inheritance. Ada 83 subtype inherits operations and 
> representation of the base type. Similarly Ada 83 cloned type (type X is 
> new Y) inherits (clones) both.
> 
> > Rather, Ada83 has type derivation and subtyping, which despite the similarity of the name subtyping with OO's subclassing (made worse by C++'s & then later Java's abuse of the term class to mean a single type instead of a tree of types), subtyping in Ada83 has nothing to do with subclassing in Ada95 or any other OO language.
> 
> Yes, but these are names for the same concept of a types algebra

Funny that you should appeal to type algebra in type theory.  In type theory, it is called ‘type extension’ not ‘inheritance’.  Only us rubes over here in tech-world, use the term inheritance as if the subclass is the heir and the superclass is the estate of the deceased.

With the precision of the mathematical term ‘type extension’ in mind, OO inheritance is extending the superclass either with additional data or additional routines or refined behavior of overridden routines.  Conversely, subtyping in Ada does none of that type-extension stuff:  no additional data/cardinality-of-the-members-of-the-set, no additional routines/behavior, no arbitrary refinement of behavior of overridden/copied routines/operations.  Instead, subtyping in Ada is strictly subjecting the parent type to an additional membership-narrowing predicate, such as subset in set theory.  Randy likewise spoke of membership on other branches of this thread.

Narrowing set membership is not inheritance.  For example, compile-time-enforced null exclusion is all the rage in the {Swift, Kotlin, C#} languages and their eras of language definition.  Clearly, null exclusion is a special case of Ada's subtying applied to the topic of von Neumann addresses (e.g., pointers, references, access, or whatever is the jargon du jour):  can the address be not-an-address* in the von Neumann address space?  Mere subsets are not inheritance.

* null, in the vernacular.

Clearly, in mathematics, narrowing set membership from integers to, say, natural numbers is not inheritance.  In natural numbers, the additive identity (i.e., zero) that integers had is missing, and along with that omission any operation, theorem, or behavior that integers had that depended on the additive identity has been elided from the subtype natural numbers.  In natural numbers, the additive inverse (i.e., negative numbers) that integers had is missing, and along with that omission any operation, theorem, or behavior that integers had that depended on additive inverse has been elided from the subtype natural numbers.  Mere subsets are not inheritance.

So right there we not only see the failure of grand concepts as Liskov substitution principle, but we also see much more mundane failures for natural numbers to substitute in all of integers' interfaces to reality:  the •copying• of operations that Randy & I mention and the •reworking• of copied operations to comply with narrowed restrictions doesn't even happen at all for numerous characteristics of the parent type.  They are simply not copied at all to the narrowed-membership subtype.  There is no analogue of that not-there-at-all elision of characteristics of the parent type in inheritance.

When it looks like a duck and quacks like a duck but can't hatch & eat & mate but instead needs batteries, then it isn't a duck; it is a hunter's decoy or a child's toy.  Inheritance = duck.  Ada's subtyping = not a duck.
 
> operation when a new type is produced from an old type by *inheriting* 
> some of the operations and representations of the old.

No, as Randy said along a different branch of this thread, the operations are not inherited; they are “copied” (i.e., taken as mere inspiration) and …
1) in subtypes:  … reworked to the narrower restrictions of the subset of the subtype (e.g., different out-of-range checks)
or
2) in derived types:  … made incompatible to be called using the parent type and vice versa when appearing as parameters to routines.

Neither #1 nor #2 are properties of type extension.

> Different are the ways of inheritance and methods of achieving 
> substitutability.

Funny that you should bring up substitutability.  In derived types there is no substitutability between parent and derived type (except in some ways of declaring parameterized-type/generic parameters).

There exists a conceptual model for examining substitutability:
Referring to
https://en.wikipedia.org/wiki/Covariance_and_contravariance_(computer_science)#Inheritance_in_object-oriented_languages

where T' is a derived type of T, there is no invariance, no covariance, and no contravariance because T' is not substitutable for T, hence T' did not inherit from T.

where T' is a subtype of T in the Ada sense (but not speaking of the Java or C++ sense), there is the opportunity in language design for

a) covariance of return type (subclass returns a more-restricted T' to override superclass's function-method that returns T)

b) contravariance of parameters to routines (subclass takes a T parameter to override a superclass's method that takes a more-restricted T' parameter)

c) [unwisely, as in Eiffel] covariance of parameters to routines (subclass takes a more-restricted T' parameter to override a superclass's method that takes a T parameter)

> Ada 95 introduced a new (for Ada) method in addition 
> to the methods Ada 83 already had.
> 
> -- 
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de

Re: about inheritance of subtypes and entities (such as constants) related to a type in the same package

[Dan'l Miller]

On Thursday, May 31, 2018 at 9:29:04 AM UTC-5, Dan'l Miller wrote:
> 2) in derived types:  … made incompatible to be called using the parent type and vice versa when appearing
> as parameters to routines.

I misspoke by trying to be too concise there in the “vice versa”.  I meant:  … made incompatible to be called using the parent type or any other subtypes of the parent when the subtype appears as parameters to routines.

Lack of ability to substitute a parent for a subtype and lack of ability to substitute peer subtypes among a class-of-subtypes are anti-properties of inheritance, i.e., counter-examples disproving inheritance.

Re: about inheritance of subtypes and entities (such as constants) related to a type in the same package

[Dmitry A. Kazakov]

On 2018-05-31 04:29 PM, Dan'l Miller wrote:
> On Thursday, May 31, 2018 at 3:54:22 AM UTC-5, Dmitry A. Kazakov wrote:
>> On 2018-05-30 10:53 PM, Dan'l Miller wrote:
>>
>>> Yes, I realize that this thread is speaking colloquially in retrospect about Ada83 features as primordial pre-OO.  But the OP's entire topic is predicated on subtyping and type-derivation of non-tagged types that then abuses the OO/Ada95 term "inheritance" as a proleptic anachronism, back misapplying inheritance to the entirely-different Ada83 language that clearly lacks inheritance, in both name and spirit (or primordial soup thereof).
>>
>> No, it is still inheritance. Ada 83 subtype inherits operations and
>> representation of the base type. Similarly Ada 83 cloned type (type X is
>> new Y) inherits (clones) both.
>>
>>> Rather, Ada83 has type derivation and subtyping, which despite the similarity of the name subtyping with OO's subclassing (made worse by C++'s & then later Java's abuse of the term class to mean a single type instead of a tree of types), subtyping in Ada83 has nothing to do with subclassing in Ada95 or any other OO language.
>>
>> Yes, but these are names for the same concept of a types algebra
> 
> Funny that you should appeal to type algebra in type theory.  In type theory, it is called ‘type extension’ not ‘inheritance’.  Only us rubes over here in tech-world, use the term inheritance as if the subclass is the heir and the superclass is the estate of the deceased.

A new type need not to be extension to inherit from another type. 
Nothing prevents from having type "subtraction" or absolutely unrelated 
representation.

[There is a quite misunderstanding about what can be a subtype, e.g. 
LSP. It is based on well-meant alas unrealistic idea. There is nothing 
that can enforce substitutablity at the level of types.]

> With the precision of the mathematical term ‘type extension’ in mind, OO inheritance is extending the superclass either with additional data or additional routines or refined behavior of overridden routines.

Inheritance does not extend anything (e.g. in the sense of a set 
product), as the name suggests it merely inherits some interface, some 
operation implementation, some parts of representation.

> Conversely, subtyping in Ada does none of that type-extension stuff:  no additional data/cardinality-of-the-members-of-the-set, no additional routines/behavior, no arbitrary refinement of behavior of overridden/copied routines/operations.  Instead, subtyping in Ada is strictly subjecting the parent type to an additional membership-narrowing predicate, such as subset in set theory.  Randy likewise spoke of membership on other branches of this thread.

Untrue. Ada 83 subtyping extends the supertype (base type), because it 
exports operations defined on the subtype to the base type. Ada 83 
subtyping introduces an equivalent type, which is both sub- and 
supertype of the base.

> Narrowing set membership is not inheritance.

Firstly, as I explained LSP-subtyping does not define inheritance.

Secondly, regarding substitutability your statement is wrong. Narrowing 
the set of values (specialization) warranties substitutability of 
out-operations. Consider this:

    procedure Foo (X : out Positive);

an Integer is trivially substitutable in Foo.

To summarize:

1. Generalization violates out-operations
2. Specialization violates in-operations
3. in out-operations are always violated

> Clearly, in mathematics, narrowing set membership from integers to, say, natural numbers is not inheritance.

The corresponding mathematical structure is a category, not set.

> So right there we not only see the failure of grand concepts as Liskov substitution principle, but we also see much more mundane failures for natural numbers to substitute in all of integers' interfaces to reality:  the •copying• of operations that Randy & I mention and the •reworking• of copied operations to comply with narrowed restrictions doesn't even happen at all for numerous characteristics of the parent type.  They are simply not copied at all to the narrowed-membership subtype.  There is no analogue of that not-there-at-all elision of characteristics of the parent type in inheritance.

Yes, Ada subtype /= LSP subtype, which should not worry anybody, because 
LSP subtypes are useless since no two non-trivial types can enjoy LSP 
relationship.

>> operation when a new type is produced from an old type by *inheriting*
>> some of the operations and representations of the old.
> 
> No, as Randy said along a different branch of this thread, the operations are not inherited; they are “copied” (i.e., taken as mere inspiration)

Yes, but inheritance is still present because Ada requires existence of 
a subtype for each type. So the cloning:

    type X is new Y;

First clones the representation and operation. And then inherits all 
everything in its first subtype.

> and …
> 1) in subtypes:  … reworked to the narrower restrictions of the subset of the subtype (e.g., different out-of-range checks)
> or
> 2) in derived types:  … made incompatible to be called using the parent type and vice versa when appearing as parameters to routines.
> 
> Neither #1 nor #2 are properties of type extension.

Surely you can add new operations = extend the interface. You can also 
disallow operations.

BTW, useful terms are type specialization and type generalization.

And type /= set of its values.

>> Different are the ways of inheritance and methods of achieving
>> substitutability.
> 
> Funny that you should bring up substitutability.  In derived types there is no substitutability between parent and derived type (except in some ways of declaring parameterized-type/generic parameters).

An object of Ada subtype is substitutable for its base type and 
conversely in the sense that Ada does consider this type violation. The 
behavior changes as constraints checks added to the inherited 
implementation.

> There exists a conceptual model for examining substitutability:
> Referring to
> https://en.wikipedia.org/wiki/Covariance_and_contravariance_(computer_science)#Inheritance_in_object-oriented_languages

Ada subtype is an equivalent type, which makes covariance and 
contravariance same.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: about inheritance of subtypes and entities (such as constants) related to a type in the same package

[Dan'l Miller]

On Thursday, May 31, 2018 at 12:37:07 PM UTC-5, Dmitry A. Kazakov wrote:
> On 2018-05-31 04:29 PM, Dan'l Miller wrote:
> > Conversely, subtyping in Ada does none of that type-extension stuff:  no
> > additional data/cardinality-of-the-members-of-the-set, no additional
> > routines/behavior, no arbitrary refinement of behavior of overridden/copied
> > routines/operations.  Instead, subtyping in Ada is strictly subjecting the
> > parent type to an additional membership-narrowing predicate, such as subset
> > in set theory.  Randy likewise spoke of membership on other branches of this
> > thread.
> 
> Untrue. Ada 83 subtyping extends the supertype (base type), because it 
> exports operations defined on the subtype to the base type. Ada 83 
> subtyping introduces an equivalent type, which is both sub- and 
> supertype of the base.

If Ada83 untagged subtyping is type extension, please provide even a single characteristic that was extended/added/supplemented instead of contracted/subtracted/elided by the predicate.  It seems that the only thing actually extended/added/supplemented in a subtype is logical conjunction (i.e., and) of another predicate.  Copied (as from an exemplar) is a better term than inherited.

Indeed, in Ada, the parent untagged type and untagged subtype need not share the same representation.  Not even representation is necessarily inherited by the subtype from the parent type.  And if representation of the subtype can differ, then this so-called inheritance of subtypes from parent types really does look more like things that do versus don't get copied from a prior exemplar via rules governing that copying-from-exemplar.

Clearly, mechanical copying-from-exemplar some things but not others is not type extension.  (Only type extension is inheritance.)  Type extension is taking the whole parent type without all this piecemeal elision-surgery (as a whole enchilada) and actually •adding• something more substantial than a predicate to it (so that now the whole enchilada now has some sauce or a side of rice and beans added to it).

Btw, I realize that Ada's _LRM_ utilizes 1,000 times the term "inherit" colloquially in the sense of OP's and Dmitry's usage.  Based on my exploration of the _LRM_, it never normatively states a definition for what inheritance is versus is not with respect to untagged types.  The _LRM_ just uses the term inherit colloquially with respect to untagged types.  In all the places where the _LRM_ colloquially uses "inherit", it could have utilized "receive" instead to emphasize the copy-from-prior-exemplar truly-intended meaning.  The OP's gotcha point is deftly dismantled by changing the colloquialism from inherit to receive.  Upon realization that "inherit" is a mere colloquialism used for convenience in the _LRM_ regarding untagged types, suddenly Ada83's receiving-from-prior-exemplar semantics regarding untagged types versus Ada95-onward's inheriting semantics regarding tagged types
1) no longer looks botched as some sort of philosophical mismatch,
2) no longer looks like a Ichbiah-versus-Taft conceptual tug of war for control of the steering wheel of the rudder of Ship Ada,
and
3) no longer has the (OP's) linguistic ability to point out gotchas where Ada83's receiving-from-prior-exemplar does not conform to expectations of modern OO inheritance.

A simple mental hygiene of not (ab)using a term (i.e., "inherit") where it shouldn't have been utilized in specifying Ada causes the entire OP's gotcha to go poof.

Conversely, over the years since the advent of the Ada9X project, the ARG did an excellent job of overtly capturing what inheritance means for tagged types:  the canonical OO definition of single inheritance without multiple dispatch with zero or more inherited interfaces.  It has none of Ada83-subtyping's piecemeal dismantling of the enchilada via rules to copy-from-exemplar some piecepart-internals of the enchilada but not others.  Why?  Because inheritance doesn't do that (but subtyping's rule-based copy-from-exemplar does).

Re: about inheritance of subtypes and entities (such as constants) related to a type in the same package

[Dmitry A. Kazakov]

On 2018-05-31 20:53, Dan'l Miller wrote:
> On Thursday, May 31, 2018 at 12:37:07 PM UTC-5, Dmitry A. Kazakov wrote:
>> On 2018-05-31 04:29 PM, Dan'l Miller wrote:
>>> Conversely, subtyping in Ada does none of that type-extension stuff:  no
>>>   additional data/cardinality-of-the-members-of-the-set, no additional
>>   > routines/behavior, no arbitrary refinement of behavior of overridden/copied
>>>   routines/operations.  Instead, subtyping in Ada is strictly subjecting the
>>>   parent type to an additional membership-narrowing predicate, such as subset
>>   > in set theory.  Randy likewise spoke of membership on other branches of this
>>   > thread.
>>
>> Untrue. Ada 83 subtyping extends the supertype (base type), because it
>> exports operations defined on the subtype to the base type. Ada 83
>> subtyping introduces an equivalent type, which is both sub- and
>> supertype of the base.
> 
> If Ada83 untagged subtyping is type extension, please provide even a single characteristic that was extended/added/supplemented instead of contracted/subtracted/elided by the predicate.

Elementary:

    subtype Extension is Integer;
    procedure Extended_Operation (X : Extension) is null;
    X : Integer;
    Y : Extension;
begin
    Extended_Operation (X); -- See #1
    Extended_Operation (Y); -- See #2

The subtype Extension extends Integer with Extended_Operation, which has 
two separate meanings:

1. The base type Integer has now a new operation:

    new Integer interface = old Integer interface + Extended_Operation

2. The subtype Extension extends inherited Integer's set of operations:

    Extended interface = old Integer interface + Extended_Operation

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: about inheritance of subtypes and entities (such as constants) related to a type in the same package

[Dan'l Miller]

On Thursday, May 31, 2018 at 2:59:48 PM UTC-5, Dmitry A. Kazakov wrote:
> On 2018-05-31 20:53, Dan'l Miller wrote:
> > On Thursday, May 31, 2018 at 12:37:07 PM UTC-5, Dmitry A. Kazakov wrote:
> >> On 2018-05-31 04:29 PM, Dan'l Miller wrote:
> >>> Conversely, subtyping in Ada does none of that type-extension stuff:  no
> >>>   additional data/cardinality-of-the-members-of-the-set, no additional
> >>   > routines/behavior, no arbitrary refinement of behavior of overridden/copied
> >>>   routines/operations.  Instead, subtyping in Ada is strictly subjecting the
> >>>   parent type to an additional membership-narrowing predicate, such as subset
> >>   > in set theory.  Randy likewise spoke of membership on other branches of this
> >>   > thread.
> >>
> >> Untrue. Ada 83 subtyping extends the supertype (base type), because it
> >> exports operations defined on the subtype to the base type. Ada 83
> >> subtyping introduces an equivalent type, which is both sub- and
> >> supertype of the base.
> > 
> > If Ada83 untagged subtyping is type extension, please provide even a single characteristic that was extended/added/supplemented instead of contracted/subtracted/elided by the predicate.
> 
> Elementary:
> 
>     subtype Extension is Integer;
>     procedure Extended_Operation (X : Extension) is null;
>     X : Integer;
>     Y : Extension;
> begin
>     Extended_Operation (X); -- See #1
>     Extended_Operation (Y); -- See #2

There is exactly one procedure Extended_Operation, which despite its cleverly-deceptive name is not a demonstration of type extension:  We start with having a single procedure that takes X as a parameter and that is precisely where we end:  no new procedure for Y, no additional storage for Y beyond Y's Xness, no new outcome in the execution of that procedure when passed a Y (except enforcement of the [unfortunately-missing] predicate as a post-condition).

Or in fewer words:  nothing about Y is X-plus-more.  There is no "more" there.
(not even a predicate to enforce, which would have made this example a tad juicier).

> The subtype Extension extends Integer with Extended_Operation, which has 
> two separate meanings:
> 
> 1. The base type Integer has now a new operation:
> 
>     new Integer interface = old Integer interface + Extended_Operation
> 
> 2. The subtype Extension extends inherited Integer's set of operations:
> 
>     Extended interface = old Integer interface + Extended_Operation

Invoking the same subprogram again (even with a potentially-created temporary) is not adding something to X to make a bigger-better Y.  Type extension needs some sort of •extension• whatsoever.  Extension whatsoever needs something extant to have been added/supplemented/made-more-of-it, e.g., additional storage, additional subprograms (not the same one invoked twice), additional something-quantifiable or something-tangible beyond mere narrowed post-condition range enforcement and beyond mere temporary creation iff Y's representation were to differ from X's (due to some range-restriction predicate, which was unfortunately omitted here).

Perhaps something is getting lost in translation to a nonEnglish language at the fundamental meaning-of-words level:  extend is ex- (outside of) + -tend (to regularly have a characteristic) so, by those lexemes, Y extends X directly means Y regularly has a characteristic outside of X, where characteristic is not empty set and where "outside of X" is beyond X's well-defined perimeter of self that demarcates X from all things not-X in the universe.  Y has no such extant characteristic that you or I can point to (e.g., what's its name?; where's its storage?; what's its lifetime?) that exists somewhere/anywhere in the not-X universe.  (And I don't count Y's would-be predicate, because the entire purpose of the predicate is to be subtractive/restrictive to be less-of-X, not expansively X-plus-more.)

Y merely copied some characteristics (but not others, depending on the would-be predicate) from a prior exemplar named X.  Y can be utilized wherever the exemplar was utilized.  Nothing more.  And it is that "more" there for which we are so desperately looking:  the extant expansionistic/not-contractionistic thingy that Y tended to be outside of being an X.  Y needs to find that quantifiable/tangible extant thingy outside of being an X to be an extension, to then in turn be type extension.  Nothing in Y outside of its Xness would imply no extension.  No extension would imply no type extension in Ada83's subtyping.  No type extension would imply no inheritance in Ada83's subtyping.  And when we went on that safari-hunt for that "more" thingy there, we found "nothing".  Nothing is not an extant thingy.  That chain of sought-for implications are thus true.  Q.E.D.

Re: about inheritance of subtypes and entities (such as constants) related to a type in the same package

[Dmitry A. Kazakov]

On 2018-05-31 11:10 PM, Dan'l Miller wrote:
> On Thursday, May 31, 2018 at 2:59:48 PM UTC-5, Dmitry A. Kazakov wrote:
>> On 2018-05-31 20:53, Dan'l Miller wrote:
>>> On Thursday, May 31, 2018 at 12:37:07 PM UTC-5, Dmitry A. Kazakov wrote:
>>>> On 2018-05-31 04:29 PM, Dan'l Miller wrote:
>>>>> Conversely, subtyping in Ada does none of that type-extension stuff:  no
>>>>>    additional data/cardinality-of-the-members-of-the-set, no additional
>>>>    > routines/behavior, no arbitrary refinement of behavior of overridden/copied
>>>>>    routines/operations.  Instead, subtyping in Ada is strictly subjecting the
>>>>>    parent type to an additional membership-narrowing predicate, such as subset
>>>>    > in set theory.  Randy likewise spoke of membership on other branches of this
>>>>    > thread.
>>>>
>>>> Untrue. Ada 83 subtyping extends the supertype (base type), because it
>>>> exports operations defined on the subtype to the base type. Ada 83
>>>> subtyping introduces an equivalent type, which is both sub- and
>>>> supertype of the base.
>>>
>>> If Ada83 untagged subtyping is type extension, please provide even a single characteristic that was extended/added/supplemented instead of contracted/subtracted/elided by the predicate.
>>
>> Elementary:
>>
>>      subtype Extension is Integer;
>>      procedure Extended_Operation (X : Extension) is null;
>>      X : Integer;
>>      Y : Extension;
>> begin
>>      Extended_Operation (X); -- See #1
>>      Extended_Operation (Y); -- See #2
> 
> There is exactly one procedure Extended_Operation, which despite its cleverly-deceptive name is not a demonstration of type extension:  We start with having a single procedure that takes X as a parameter and that is precisely where we end:  no new procedure for Y, no additional storage for Y beyond Y's Xness, no new outcome in the execution of that procedure when passed a Y (except enforcement of the [unfortunately-missing] predicate as a post-condition).

Interface was extended. Implementation details as to how many bodies 
there will be used are irrelevant.

> Or in fewer words:  nothing about Y is X-plus-more.  There is no "more" there.
> (not even a predicate to enforce, which would have made this example a tad juicier).
> 
>> The subtype Extension extends Integer with Extended_Operation, which has
>> two separate meanings:
>>
>> 1. The base type Integer has now a new operation:
>>
>>      new Integer interface = old Integer interface + Extended_Operation
>>
>> 2. The subtype Extension extends inherited Integer's set of operations:
>>
>>      Extended interface = old Integer interface + Extended_Operation
> 
> Invoking the same subprogram

Same to what? The interface of Integer as defined by the standard does 
not have Extended_Operation. How is it same?

> Y merely copied some characteristics (but not others, depending on the would-be predicate) from a prior exemplar named X.

You seems confuse:

1. a type with a set of values. Type = set of values + operations. 
Extension of a type, logically, is about adding something to any of these.

2. an extension of a type with a tagged record extension. A record 
extension is an extension but the reverse is wrong.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: about inheritance of subtypes and entities (such as constants) related to a type in the same package

[Dan'l Miller]

On Friday, June 1, 2018 at 2:56:55 AM UTC-5, Dmitry A. Kazakov wrote:
> On 2018-05-31 11:10 PM, Dan'l Miller wrote:
> > On Thursday, May 31, 2018 at 2:59:48 PM UTC-5, Dmitry A. Kazakov wrote:
> >> On 2018-05-31 20:53, Dan'l Miller wrote:
> >>> On Thursday, May 31, 2018 at 12:37:07 PM UTC-5, Dmitry A. Kazakov wrote:
> >>>> On 2018-05-31 04:29 PM, Dan'l Miller wrote:
> >>>>> Conversely, subtyping in Ada does none of that type-extension stuff:  no
> >>>>>    additional data/cardinality-of-the-members-of-the-set, no additional
> >>>>    > routines/behavior, no arbitrary refinement of behavior of overridden/copied
> >>>>>    routines/operations.  Instead, subtyping in Ada is strictly subjecting the
> >>>>>    parent type to an additional membership-narrowing predicate, such as subset
> >>>>    > in set theory.  Randy likewise spoke of membership on other branches of this
> >>>>    > thread.
> >>>>
> >>>> Untrue. Ada 83 subtyping extends the supertype (base type), because it
> >>>> exports operations defined on the subtype to the base type. Ada 83
> >>>> subtyping introduces an equivalent type, which is both sub- and
> >>>> supertype of the base.
> >>>
> >>> If Ada83 untagged subtyping is type extension, please provide even a single characteristic that was extended/added/supplemented instead of contracted/subtracted/elided by the predicate.
> >>
> >> Elementary:
> >>
> >>      subtype Extension is Integer;
> >>      procedure Extended_Operation (X : Extension) is null;
> >>      X : Integer;
> >>      Y : Extension;
> >> begin
> >>      Extended_Operation (X); -- See #1
> >>      Extended_Operation (Y); -- See #2
> > 
> > There is exactly one procedure Extended_Operation, which despite its cleverly-deceptive name is not a demonstration of type extension:  We start with having a single procedure that takes X as a parameter and that is precisely where we end:  no new procedure for Y, no additional storage for Y beyond Y's Xness, no new outcome in the execution of that procedure when passed a Y (except enforcement of the [unfortunately-missing] predicate as a post-condition).
> 
> Interface was extended. Implementation details as to how many bodies 
> there will be used are irrelevant.
> 
> > Or in fewer words:  nothing about Y is X-plus-more.  There is no "more" there.
> > (not even a predicate to enforce, which would have made this example a tad juicier).
> > 
> >> The subtype Extension extends Integer with Extended_Operation, which has
> >> two separate meanings:
> >>
> >> 1. The base type Integer has now a new operation:
> >>
> >>      new Integer interface = old Integer interface + Extended_Operation
> >>
> >> 2. The subtype Extension extends inherited Integer's set of operations:
> >>
> >>      Extended interface = old Integer interface + Extended_Operation
> > 
> > Invoking the same subprogram
> 
> Same to what? The interface of Integer as defined by the standard does 
> not have Extended_Operation. How is it same?

(How clever that you snipped my already-existing answer to your question at precisely the word where it becomes the inconvenient answer.  The elided original answer is restored as the next quotation below.)

Extended_Operation is merely invoked twice.  Extended_Operation is •the same• as itself, regardless if passed X as an argument or passed Y as an argument.

If Extended_Operation were named GiveTheKidABath instead, it would be obvious to all readers that giving two kids {X, Y} a bath, does not extend Y by growth and does not extend the size of the family by birthing more babies.  Nothing whatsoever was extended by invoking Extended_Operation against both X and Y.  Despite its cleverly-deceptive name (and despite invoking that subprogram twice), there is no extension whatsoever in Y beyond Y's Xness.  If Y was declared with a predicate, then Y would actually demonstrate some contraction of Xness.  Contraction (smaller domain) is not extension (bigger size or bigger mission) either.

> Invoking the same subprogram again (even with a potentially-created temporary) is not adding
> something to X to make a bigger-better Y.  Type extension needs some sort of •extension• whatsoever. 
> Extension whatsoever needs something extant to have been added/supplemented/made-more-of-it,
> e.g., additional storage, additional subprograms (not the same one invoked twice), additional something
> quantifiable or something-tangible beyond mere narrowed post-condition range enforcement and
> beyond mere temporary creation iff Y's representation were to differ from X's (due to some range
> restriction predicate, which was unfortunately omitted here). 

Attention maintainers:  the inability to determine the correct meaning of my “Invoking the same subprogram again” in the context of
>>      Extended_Operation (X); -- See #1 
>>      Extended_Operation (Y); -- See #2 
is clearly failing the Turing test due to A-is-A or A-is-itself not being understood at all.  Time flies like an arrow, but fruit flies like a banana, eh?

I think that this is crystal-clear evidence of what is going on here.

Re: about inheritance of subtypes and entities (such as constants) related to a type in the same package

[Dmitry A. Kazakov]

On 2018-06-01 16:01, Dan'l Miller wrote:
> On Friday, June 1, 2018 at 2:56:55 AM UTC-5, Dmitry A. Kazakov wrote:
>> On 2018-05-31 11:10 PM, Dan'l Miller wrote:
>>> On Thursday, May 31, 2018 at 2:59:48 PM UTC-5, Dmitry A. Kazakov wrote:
>>>> On 2018-05-31 20:53, Dan'l Miller wrote:
>>>>> On Thursday, May 31, 2018 at 12:37:07 PM UTC-5, Dmitry A. Kazakov wrote:
>>>>>> On 2018-05-31 04:29 PM, Dan'l Miller wrote:
>>>>>>> Conversely, subtyping in Ada does none of that type-extension stuff:  no
>>>>>>>     additional data/cardinality-of-the-members-of-the-set, no additional
>>>>>>     > routines/behavior, no arbitrary refinement of behavior of overridden/copied
>>>>>>>     routines/operations.  Instead, subtyping in Ada is strictly subjecting the
>>>>>>>     parent type to an additional membership-narrowing predicate, such as subset
>>>>>>     > in set theory.  Randy likewise spoke of membership on other branches of this
>>>>>>     > thread.
>>>>>>
>>>>>> Untrue. Ada 83 subtyping extends the supertype (base type), because it
>>>>>> exports operations defined on the subtype to the base type. Ada 83
>>>>>> subtyping introduces an equivalent type, which is both sub- and
>>>>>> supertype of the base.
>>>>>
>>>>> If Ada83 untagged subtyping is type extension, please provide even a single characteristic that was extended/added/supplemented instead of contracted/subtracted/elided by the predicate.
>>>>
>>>> Elementary:
>>>>
>>>>       subtype Extension is Integer;
>>>>       procedure Extended_Operation (X : Extension) is null;
>>>>       X : Integer;
>>>>       Y : Extension;
>>>> begin
>>>>       Extended_Operation (X); -- See #1
>>>>       Extended_Operation (Y); -- See #2
>>>
>>> There is exactly one procedure Extended_Operation, which despite its cleverly-deceptive name is not a demonstration of type extension:  We start with having a single procedure that takes X as a parameter and that is precisely where we end:  no new procedure for Y, no additional storage for Y beyond Y's Xness, no new outcome in the execution of that procedure when passed a Y (except enforcement of the [unfortunately-missing] predicate as a post-condition).
>>
>> Interface was extended. Implementation details as to how many bodies
>> there will be used are irrelevant.
>>
>>> Or in fewer words:  nothing about Y is X-plus-more.  There is no "more" there.
>>> (not even a predicate to enforce, which would have made this example a tad juicier).
>>>
>>>> The subtype Extension extends Integer with Extended_Operation, which has
>>>> two separate meanings:
>>>>
>>>> 1. The base type Integer has now a new operation:
>>>>
>>>>       new Integer interface = old Integer interface + Extended_Operation
>>>>
>>>> 2. The subtype Extension extends inherited Integer's set of operations:
>>>>
>>>>       Extended interface = old Integer interface + Extended_Operation
>>>
>>> Invoking the same subprogram
>>
>> Same to what? The interface of Integer as defined by the standard does
>> not have Extended_Operation. How is it same?
> 
> (How clever that you snipped my already-existing answer to your question at precisely the word where it becomes the inconvenient answer.  The elided original answer is restored as the next quotation below.)
> 
> Extended_Operation is merely invoked twice.  Extended_Operation is •the same• as itself, regardless if passed X as an argument or passed Y as an argument.

But X and Y are declared of different subtypes. How can it be same?

> If Extended_Operation were named GiveTheKidABath instead, it would be obvious to all readers that giving two kids {X, Y} a bath, does not extend Y by growth and does not extend the size of the family by birthing more babies.  Nothing whatsoever was extended by invoking Extended_Operation against both X and Y.  Despite its cleverly-deceptive name (and despite invoking that subprogram twice), there is no extension whatsoever in Y beyond Y's Xness.  If Y was declared with a predicate, then Y would actually demonstrate some contraction of Xness.  Contraction (smaller domain) is not extension (bigger size or bigger mission) either.

Again, Integer does not have Extended_Operation. Try this:

    procedure Test is
       X : Integer;
    begin
       Extended_Operation (X);
    end Test;

does it compile? No.

    procedure Test is
       subtype Extension is Integer;
       procedure Extended_Operation (X : Extension) is null;
       X : Integer;
    begin
       Extended_Operation (X);
    end Test;

Does it compile now? Yes.

What happened with the Integer type?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: about inheritance of subtypes and entities (such as constants) related to a type in the same package

[Randy Brukardt]

"Dan'l Miller" <optikos@verizon.net> wrote in message 
news:534965d3-e494-476b-8a91-6cf9f376c020@googlegroups.com...
...
>Btw, I realize that Ada's _LRM_ utilizes 1,000 times the term "inherit" 
>colloquially
>in the sense of OP's and Dmitry's usage.

Nothing "colloquially" about it: any term not defined in the RM is used in 
its English language sense, and specifically from a definition based on a 
particular dictionary (see 1.3). (Well, there's an exception for 
mathematical terms, but "inherit" surely isn't one of those.

In any case, I'm only interested in the terminology of the RM when it comes 
to discussing Ada. Dmitry has taught me well that there is no point is 
spending a moment arguing with someone that uses words in some other way - 
it's virtually impossible even understand what they're actually talking 
about. So I'm not going to waste any more time in this subthread.

                                       Randy.

Re: about inheritance of subtypes and entities (such as constants) related to a type in the same package

[Dan'l Miller]

On Thursday, May 31, 2018 at 5:45:37 PM UTC-5, Randy Brukardt wrote:
> "Dan'l Miller" wrote in message 
> news:534965d3-e494-476b-8a91-6cf9f376c020@googlegroups.com...
> ...
> >Btw, I realize that Ada's _LRM_ utilizes 1,000 times the term "inherit" 
> >colloquially
> >in the sense of OP's and Dmitry's usage.
> 
> Nothing "colloquially" about it: any term not defined in the RM is used in 
> its English language sense, and specifically from a definition based on a 
> particular dictionary (see 1.3). (Well, there's an exception for 
> mathematical terms, but "inherit" surely isn't one of those.
> 
> In any case, I'm only interested in the terminology of the RM when it comes 
> to discussing Ada. Dmitry has taught me well that there is no point is 
> spending a moment arguing with someone that uses words in some other way - 
> it's virtually impossible even understand what they're actually talking 
> about. So I'm not going to waste any more time in this subthread.
> 
>                                        Randy.

Well, Pierre America said in 1989 substantially the same thing as I did above about inheritance being different than subtyping, and thus needing two distinct non-conflated terms:

https://www.researchgate.net/publication/234789659_A_behavioural_approach_to_subtyping_in_object-oriented_programming_languages

Conversely in the conflated 2 usages of “inherit” within the _LRM_, in that dictionary, inherit has 4 transitive-verb definitions.

https://www.merriam-webster.com/dictionary/inherit

I assume that only #4 is the one that you are evoking, because #1 speaks of the divine, #2 speaks of biological death, and #3 speaks of genetics.

definition #4:
“to have in turn or •receive• as if from an ancestor”
and its example usage:
“inherited the problem from his predecessor”

In especially the example usage above in that dictionary definition, the inherited problem is from a prior •exemplar• from which the current office-holder's state has been •received• as a copy of the predecessor's state/characteristics.  The predecessor office-holder is more exemplar-to-copy than genetic ancestor passing estate on through bloodlines—thus illustrating my language in prior comments along this thread.  The current office-holder is more copy of state than heir of estate.  And in OO inheritance or Ada83 untagged subtyping, the ancestor need not die (or leave office), as in the dictionary definitions or their example usages, so there does in fact appear to be a different OO definition being utilized in the _LRM_ than the commonfolk dictionary definition of inheritance.

Re: about inheritance of subtypes and entities (such as constants) related to a type in the same package

[Dmitry A. Kazakov]

On 2018-06-01 12:45 AM, Randy Brukardt wrote:

> In any case, I'm only interested in the terminology of the RM when it comes
> to discussing Ada.

You cannot discuss Ada in Ada terms, evidently.

If you limit yourself to only Ada terms then you can only discuss Ada 
implementation and Ada usage, not the Ada itself.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: about inheritance of subtypes and entities (such as constants) related to a type in the same package

[Randy Brukardt]

"Dan'l Miller" <optikos@verizon.net> wrote in message 
news:c6b68b0d-e9f0-47a8-9692-7cba63ea1000@googlegroups.com...
On Tuesday, May 29, 2018 at 5:12:23 PM UTC-5, Randy Brukardt wrote:
...
>> long before
>> anyone really understood OOP or similar systems.
>
>Well, there was Simula in the 1960s.

Yes, I know that. But hardly anyone understood them. I recall studying 
Simula at the University of Wisconsin in the programming language class, and 
the textbook and instructors presented it as an interesting diversion from 
typical programming. (We also studied Planner and CLU in that class, along 
with more mainstream things like Lisp.) No one guessed then that a 
substantial branch of programming was going to grow out it.

Regardless of whether Ada 83 called the derived type mechanism 
"inheritance", it surely was that, and it survives virtually unchanged for 
all types in Ada 95 and later. Some additional stuff was added to it 
(especially for tagged types), and some details were nailed down better, but 
the mechanisms for subprograms in particular are identical. I thought that 
was a problem during the development of Ada 9x; no one understood derived 
types at all in Ada 83, and building the entire OOP system on top of them 
seemed like elevating an obscure bar band to the main stage at Summerfest. 
Luckily, I was mostly wrong about that.

                                                           Randy.


                               Randy.