Re: Ada Annoyances

["Randy Brukardt" <randy@rrsoftware.com>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:p169d9$6ka$1@gioia.aioe.org...
> On 2017-12-17 17:24, Mehdi Saada wrote:
>> So, some of you think the stupidity is on the side of certain
>> customers, to ban tagged types as a whole, as objetively there is no
>> added cost when we don't use 'Class types ? Rather than on the language
>> designers', for tagging controlled type and cursor etc by default ?
>> Can someone answer simply, if there is or not, really no difference
>> (save for some more bits for the tag) between regular records types and
>> tagged types, when not using class types ?
>
> There is a huge difference even without class-wide objects. Some things 
> from the top:
>
> 1. You can derive a new type from a tagged type, which you cannot do from 
> a non-tagged type

I think you are using a non-Ada meaning of "derive" here, since an Ada 
derived type works for all types.

> 2. You can clone a non-tagged type, which you cannot do with a tagged 
> type.

No idea what this means. You certainly can use a null extension on a tagged 
type, and that operates pretty much the same as a non-tagged type.

> 3. The meaning of abstract operations like
>
>    procedure Foo (X : T) is abstract;
>
> for tagged and non-tagged types is totally different

Right.

> 4. Type polymorphism is still available for tagged types without 
> class-wide objects as you can have generic formal parameters:
>
>    generic
>       type X is new Y with private;

You can do this for untagged types as well (without the "with private" 
part), it's just not very useful.

> 5. You can inherit operations of tagged types.

All derived types inherit operations. That's why the Ada 95 design used 
derivation rather than a new type construct to implement OOP.

> 6. You cannot declare certain operation signatures with tagged types due 
> to multiple-dispatch issues.

Right. But this is a subset of 9.

> 7. Declaration of tagged types are subject of freezing rules.

All types are subject to freezing rules; perhaps you meant that the 
*operations* of a tagged type are also subject to freezing rules.

> 8. Visibility of primitive operations is radically different. You can 
> reach primitive operation even if they are not visible.

You mean that prefix notation is allowed (and it has different visibility 
rules). Otherwise, the visibilty rules are the same for all types, annoying 
as that can be.

I think this one follows from the OPs original comment.

> 9. Certain signatures behave differently if arguments are tagged, e.g. 
> when several arguments are controlled the tags must be same.

Right, 6 is a subset of this one, in that there can be only one tag, and a 
number of rules are used to enforce that.


======================

I read the original question as to whether the *representation* of a tagged 
type is essentially the same as an untagged record type. And the answer to 
that is that, yes, in most cases, a tagged type is just a record type with 
an extra "tag" component. Unless there are going to be a very large number 
of objects of a type, the extra cost of a tagged type is insignificant.

The Ada 95 designers considered tagged types to be "records done right", and 
thus the different rules for them. Most of the differences are improvements 
(and at least one has been applied to all records in more recent Ada 
versions -- the equality rules). I wouldn't worry about declaring a type 
tagged unless there were likely to be thousands of objects of it being 
created.

Controlled types might be more expensive, depending upon how they are 
implemented. If a chaining implementation is used, then there are extra 
components which have to be managed. That might happen even for a mostly 
static implementation (there still are cases like allocated objects that 
have to be managed dynamically). So I'd be a bit more cautious with those, 
but again it only would matter if there are a lot of objects getting created 
and destroyed.

                                 Randy.