Re: Extending a third party tagged type while adding finalization

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On 08/12/2017 00:22, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:p0auie$h5h$1@gioia.aioe.org...
>> On 07/12/2017 02:13, Randy Brukardt wrote:
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>>> news:p07343$1tst$1@gioia.aioe.org...
>>>> On 2017-12-05 22:09, Randy Brukardt wrote:
>>> ...
>>> The above is much too complex. It could be simplified a lot:
>>>
>>> An ADT is a data type (from the perspective of a client of a type)
>>> defined solely by the operations defined for that data type.
> 
> This was a bit sloppy; it should also have required the operations to be
> defined explicitly and as a closed set of operations.

The set cannot closed, most types (and most models they implement) have 
mixed operations. And models do intersect too. This is why multiple 
inheritance is so important.

> Definitely. As I mentioned earlier, there is a closed, finite set of
> operations involved in an ADT.

This just follows from the ADT semantics. It is upfront to the ADT 
definition and implementation. That enforces certain properties on the 
operations implementing it.

The reverse is wrong. You cannot have make it ADT by merely having a 
bunch of operations in the same package.

> There can be other operations that are built
> on the set of operations, but they are definitely not part of the ADT.

How can you tell? To me it is meaningless without considering the 
semantics. If an operation implements some part of the ADT semantics, it 
is of ADT. If it does not then it is an implementation detail and must 
be hidden unless it belongs to some other ADT.

> If
> the set of operations is not closed, then one cannot abstractly reason about
> the ADT, defeating the purpose of the definition. (It also defeats
> reusability, which is rather the point of defining ADTs in the first place.

We reason about ADT implementations. ADT semantics is already defined by 
the model. The models do intersect and interact. It is not closeness you 
probably mean but rather borders between modeled entities. These borders 
are defined during the problem space analysis and enforced by the 
language typing system. Ada is strongly typed, so there is nothing to 
worry about here.

>> 1. Private type means that parts of the representation is hidden. Your
>> definition is not related to that.
> 
> All of the operations need to be explicit and a closed set.
> If the representation is not hidden, that cannot be true.

The representation can exactly match the type semantics, e.g. an 
enumeration type or discrete type:

    type Alarm is (Low, High);
    type Room_Temperature is digits ... range 0.0..30.0;

[If you consider these representations.]

There is nothing wrong in exposing representations telling the problem 
space's truths. Only implementation artifacts need to be hidden and only 
when they expose things breaking the abstraction.

> QED. (Yes, my definition
> was sloppy. So what?)

Sloppy definitions lead to sloppy conclusions ... (:-))

>> 2. Primitiveness of an operation is not related either.
> 
> If the type is private, the operations have to be declared there, and that
> makes them primitive. (No Ada ADTs outside of an Ada package.)

You can declare non-primitive operations at same places. You are trying 
to define a general concept in terms of Ada design artifacts (if not 
design faults).

>>> If a type is not private, it cannot be an ADT, as it provides an
>>> unlimited number of other operations that are not described explicitly.
>>
>> How primitiveness changes that? I still can define new subprograms taking
>> and returning values of the type regardless.
> 
> If they're not part of the package, then they are operations that use the
> ADT, but are not part of the ADT.

Now you are attempting to tie ADT with packages. Why should these be 
related. Aren't types partially defined in a chain of packages and 
completed in some other package ADT?

> For many programs, most of the code is
> built on ADTs but are not themselves part of any ADT (because they require
> the services of many ADTs - which one does it belong to? Any answer is
> arbitrary).

No you want to deny ADT reuse or abstraction. A matrix element can be 
ADT but the matrix and vector cannot because it uses element ADT?

> ...
>>> With the
>>> Wikipedia definition above, every Ada data type is an ADT, since every type
>>> can be described this way (every operation on a numeric type is described by
>>> the Ada Standard, after all, and a client can use nothing else). That's a
>>> completely useless definition.
>>
>> ADT is the semantics it implements. You first have the semantics
>> (mathematical model of the problem space) and then an implementation of.
>>
>> Non-ADT is ad-hoc semantics deduced from a given representation. You take
>> 'int' from the compiler and then try to figure out if it can be useful for
>> you.
>>
>> That is the difference.
> 
> Based on this definition, almost nothing should be an ADT, because very
> little can be described only by its semantics. Humm, that's actually a true
> statement; probably we are feeling different parts of the elephant and
> describing it very differently.

Probably. Things you cannot associate with the semantics are 
implementation aspects. They can be any so long the semantics maintained.

> Still, you seem to think of an ADT as a
> constantly increasing (and ad-hoc) set of operations, while I view only the
> operations declared directly with the (private) type as part of the ADT.

No. The way ADT is implemented does not bother me. Inheritance is a tool 
to implement ADTs. Built-in arrays, records, variant-records is another. 
Subtyping, constraining is a third. A programmer can use any of these in 
any combination in order to implement a type with the required 
semantics. The result is an ADT.

You are right that the interface of an ADT must be clear. This is why 
Ada has means for information hiding. Any aspects irrelevant to the 
semantics of the ADT must be hidden. It is not always possible in Ada 
and I always wished more help to that, especially interfaces for and of 
arrays, record, access, tasks, protected object types, constructors, 
user aggregates etc.

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