Re: User-defined type attributes

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

"Eric Hughes" <eric.eh9@gmail.com> wrote in message
news:d9065e94-8586-4889-b5c7-a8ca9e8f2248@d21g2000prf.googlegroups.com...
...
> First, a historical question: Was there a proposal for user attributes
> that was considered for Ada 2005?

Not seriously. It had been rejected for Ada 95, and in general, we didn't
want to rehash that old ground.

...
> And a related historical question: Why does the prefixed view of a
> subprogram only apply to tagged types?  It seems like a syntax
> eminently suited for any subprogram.

There are ambiguity problems because "any type" includes access types.
Recall that '.' in Ada always includes an implicit dereference (and the
prefixed notation also supports the reverse, an implicit 'Access). That is,
   A.B(C);
could mean
   B(A, C);
or
   B(A.all, C);
or
   B(A'access, C);

The latter should not be allowed for untagged types (they're not implicitly
aliased). But, also it would be possible for it to mean
  B(A.all.all, C);
and
  B(A.all.all.all, C);
and so on forever.

That caused definitional and implementation problems. So we only allowed
tagged types.

That's OK, because only tagged types work "right" in Ada. There are a number
of bizarre behaviors (one involves "=" of types with components, and another
with the "reemergence" of predefined operations inside of a generic) that
had to be retained from Ada 83 for compatibility reasons. These language
mistakes are corrected with tagged types.

Thus, I think virtually all new composite types should be tagged in Ada
programs; you'll be a lot happier for it. Keep in mind that the only runtime
overhead for a tagged object in Ada is the space for the tag and the time to
fill it in on initialization; calls are statically bound unless you use
T'Class somewhere.

I usually go further and say all new types should be controlled (so as to
get user-defined finalization), but that does have a small runtime overhead
if not used.

                               Randy.






> An attribute function must evaluate at compile-time, or perhaps more
> subtly, prior to elaboration time.  Much of the requisite apparatus is
> already present with static expressions and preelaborable packages.
> The standard would require an additional definition of the ability to
> pre-elaborate a function body.  While such a body might be restricted
> to returning a single static expression, that seem a bit restrictive.
>
> My overall motivation (as before) is to enable better, more flexible
> library support.  Library support gates usability and enables cost-
> justifiable selection of Ada in a greater number of application
> domains.  These kinds of features are not so critical for a single
> team writing their own software, but rather come into their own when
> writing libraries for other people to use in not-yet-anticipated ways.
>
> Eric