Re: Ada Annoyances

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

(1) Untagged primitive operations can be overridden "late", that causes 
problems for anything that calls them indirectly. Perhaps it could have been 
made to work, but it was more work for a feature that some people thought 
was marginal; probably it would have been dropped rather than getting more 
complicated.

(2) Iteration is defined in terms of an interface, so by definition it only 
works with tagged types. Perhaps we should have not tried to build on other 
language features and just made iteration magic all the way (it certainly 
would have been easier to use that way), but taggedness is a consequence of 
that.

(3) Since prefixed notation does automatic dereferencing and referencing 
(that is, .all and 'Access), allowing it on all types caused levels of 
ambiguity (and potentially infinite regress). It was easier to just define 
it on tagged types, which didn't have those issues. Perhaps it could have 
been made to work, but it was more work for a feature that already had 
significant opposition; probably it would have been dropped rather than 
getting more complicated. (Sound like a broken record??)

Note that for versions of Ada prior to Ada 2012, you have to use tagged 
types if you expect "=" to work right. Untagged record "=" does not compose 
in original Ada. We eventually decided to fix that, but the fix means that 
substantial existing code won't compile with Ada 2012 (most of it didn't do 
what the author intended anyway, so whether that is a bad thing is hard to 
say).

And of course if you need controlled types, you have to use tagged types. If 
you want any type extension (regardless of whether any dispatching or 
inheritance is involved), you have to use tagged types.

So you have to use tagged types in most circumstances in Ada 2012. And given 
that the extra cost is a word or two per object, the overhead is 
insignificant in most cases. (The cases where it matters, tiny non-private 
objects that are used in large quantities, are those for which the missing 
features aren't usable anyway.)

The real problem here is keeping compatibility with the messed-up 
definitions of untagged types in Ada; the most sensible thing to do would be 
to make all types effectively tagged (Dmitry likes to tell everyone how it 
ought to work), but that would be incompatible in many overriding cases. It 
would make more sense for Ada'Succ.

                               Randy.

<pythoner6@gmail.com> wrote in message 
news:3df6404a-588d-4e2d-a189-1d1e32ce9f5d@googlegroups.com...
On Friday, June 30, 2017 at 11:02:48 AM UTC-4, Norman Worth wrote:
> You should not use tagged types where they are not needed.  It messes up
> the code.  In general, if you are not going to have derived types, the
> base type should not be tagged.

In some cases you do not have a choice; this is why I started this thread in 
the first place. If you want to define custom indexing, custom iteration or 
use the object.method() syntax, you must use tagged types, regardless of 
whether or not you really need tagged types. It seems odd to me that you 
must pay an unnecessary cost to use these features just because the language 
says so (perhaps there is a reason behind the decision, but I can't see 
why), even if that cost is small.